ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » 2035 on SYSTEM.CLUSTER.TRANSMIT.QUEUE

Post new topic  Reply to topic
 2035 on SYSTEM.CLUSTER.TRANSMIT.QUEUE « View previous topic :: View next topic » 
Author Message
dev135
PostPosted: Sat Nov 26, 2011 12:11 pm    Post subject: 2035 on SYSTEM.CLUSTER.TRANSMIT.QUEUE Reply with quote

Apprentice

Joined: 21 Oct 2008
Posts: 44

MQ V 7.0.1.5
OS- AIX

have 3 qmgrs QM1,QM2,QM3

QM1-CORNISH cluster
QM2 - both in CORNISH,WINDSOR Cluster
QM3- WINDSOR cluster

I have a Q1 queue on QM1 exposed in cluster CORNISH.
We have an application user 'abc' on QM3 who wants to put a message to Q1 on QM1 . So i had created Q2 an alias cluster (WINSOR) queue pointing to Q1 . Q2 on QM2 had suffcient access for user 'abc'

But when the application tries to access Q2 ,we got 2035 issue.I know that is for SCTQ not having access for user 'abc' and i dont want to give access to SCTQ . So i changed my setup by creating the alias queue Q2 on QM3 instead of QM2 and pointing that to Q2 remote cluster( WINDSOR) queue on QM2. ( removed Q2 alias queue created earlier on QM2 and created Q2 remote cluster queue ponitng to Q1) and thats works fine.

Question - Is there any other way i can do this? because creating a remote queue for every alias queue seems like creating one more object .

Thanks
Back to top
View user's profile Send private message
mqjeff
PostPosted: Sat Nov 26, 2011 12:16 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Authorization of application actions is performed at the queue manager that the application is connected to.

So you created an object on QM2, that was visible across the cluster to QM3.

But there was no object on QM3 that the application had any access to.

So creating the object on QM2 was redundant, except that it crossed the cluster boundary.

You can choose to allow applications to route messages based only on the queue name or based only on the qmgr name, or based on both. You then need to create the necessary set of objects on the "local" qmgr that the application has the needed permissions to, and configure those objects to perform the network routing that you wish.
Back to top
View user's profile Send private message
dev135
PostPosted: Sat Nov 26, 2011 12:28 pm    Post subject: Reply with quote

Apprentice

Joined: 21 Oct 2008
Posts: 44

I had to create an object on QM2 because i need to send that message to a queue that resides on qmgr QM1 in different cluster.
I am just trying to find is there any other way the setup can be done here or i should go with QA-QR-QL here whenever we face such 2035 issue for SCTQ ?

Thanks.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Sat Nov 26, 2011 1:06 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

dev135 wrote:
I had to create an object on QM2 because i need to send that message to a queue that resides on qmgr QM1 in different cluster

not necessarily.

dev135 wrote:
I am just trying to find is there any other way the setup can be done here or i should go with QA-QR-QL here whenever we face such 2035 issue for SCTQ ?


If you want to avoid a 2035, there must exist an object on the "local" queue manager, whichever qmgr the application is connected to, that the application has permissions to.

If you want to route messages between queue managers, you can use a variety of combinations of QAs, QRs and XMITQ names. With clusters, you don't get to play around with XMITQ names.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sun Nov 27, 2011 9:02 am    Post subject: Re: 2035 on SYSTEM.CLUSTER.TRANSMIT.QUEUE Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

dev135 wrote:
MQ V 7.0.1.5
OS- AIX

have 3 qmgrs QM1,QM2,QM3

QM1-CORNISH cluster
QM2 - both in CORNISH,WINDSOR Cluster
QM3- WINDSOR cluster


This looks to be taken from the WMQ Queue Manager Clusters manual. Read a bit further. Look for a section entitled Putting across clusters in that manual.
_________________
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » 2035 on SYSTEM.CLUSTER.TRANSMIT.QUEUE
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.