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 » check remote cluster queue

Post new topic  Reply to topic Goto page Previous  1, 2
 check remote cluster queue « View previous topic :: View next topic » 
Author Message
peterw686
PostPosted: Fri Jan 23, 2004 9:52 am    Post subject: Reply with quote

Acolyte

Joined: 26 Sep 2002
Posts: 73

Hi Kumar,

Really thank you for your patience and help.

The QM3 is managed by another company, so we don't know much information about it. They just joined the cluster as a member.

Quote:
1) What userid created the Queue manager.
2) What userid owns the installation.

I don't know so far, if it's very important for this issue, I can ask them.

Quote:
3) What O/s is Qm3 running on.

As I know, their MQ is on mainframe MVS.


Quote:
4) What does your partner exactly mean, when they say, "only process the request message with USERID "MQXXX"". Does this mean they set the MCAUSER of the clusrcvr on QM3 to be MQXXX. If not, how is this authorization being imposed and how is it being verified/checked. I am not clear at all about this bit. Explain this, as this is the key to the whole issue.

This is what they sent us the description: (hope you can understand well)
Quote:
For your problem of USERID, when we said to use MQXXX as the USERID, we mean to put this userid(MQXXX) into the message descriptor of the message. There is a field for this.

because we are using JMS, there is no a direct way to set up MQMD, the only way I know of setting this is via
Code:
qcon = qconFactory.createQueueConnection(userID, null);
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Fri Jan 23, 2004 9:55 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

mqonnet wrote:

""""""""""""""
Does this mean on QM1 local machine, we should define a user "MQXXX"?
""""""""""""""

You got it just the opposite of what i meant and what it says.

Yeah. But it might work if he did it backwards like that.

Remember, QM3 is out of his hands - it's at the partner site.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri Jan 23, 2004 10:43 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Jeff,
"Yeah. But it might work if he did it backwards like that.

Remember, QM3 is out of his hands - it's at the partner site"
A) It Won't work that way. Authorizations are not done on the local end(QM1). All authorizations are failing on QM3(remote/client end).

Peter,
Unless we get the answer for Q4, it might be difficult to get to any definite answer. But from what you said here,
"For your problem of USERID, when we said to use MQXXX as the USERID, we mean to put this userid(MQXXX) into the message descriptor of the message. There is a field for this. "

it sure smells like the Customer has put in something like this. I shall try it out when i get a chance.

But for now, let us try and concentrate on other aspects, the ones that are under your control.

1) From one of your earlier posts you said this.
"If I use MQXXX as user id at first call, I will get 2035 error because QM1 doesn't have such user ID setup. If I don't use MQXXX, I can pass through the QM1, however, when it forward message to QM3, QM3 will return it back for unknown user.
"
a) What is the setup.
b) What Qm is your app connecting to.
c) What queue is it trying to put message to.
d) If the queue is a clustered queue and is not local to QM1, is it visible to QM1 when you issue dis qcluster(*).
e) When you use MQXXX userid, what api call fails and with what reason code(from what you say it should fail with 2035).
e) How are you passing MQXXX userid in your app.

2) Did you infact try the above scenario or is it just your opinion. ie. putting a message using and not using userid MQXXX.
3) Are you by any chance connecting to QM3 directly, i know in some of your posts you mentioned you dont, but just confirming.
4) If you are logged in as "mqm" on QM1 machine, and try to put to RequestQ on QM3 without specifying userid MQXXX, then i would expect the put to pass on QM3 if you have a princpial/userid defined as "mqm". Remember "mqm" userid is different from group "mqm".

The problem we are unable to resolve this after all this is because there are so many unknowns, i have posted in my previous post one list, in this one i have posted the next one. So, unless we have more info, its really difficult to resolve your situation.

Hope this clarifies things.

Cheers
Kumar
Back to top
View user's profile Send private message Send e-mail Visit poster's website
peterw686
PostPosted: Fri Jan 23, 2004 11:21 am    Post subject: Reply with quote

Acolyte

Joined: 26 Sep 2002
Posts: 73

Hi Kumar,

I tried to put scenario clear as I can. However, like you said, there are some information is our of my hand. I will try to get more information from QM3 and put it all here.

Thanks for your great help.
Peter
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Fri Jan 23, 2004 11:44 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Kumar -
This is the way I read what he's said.
  1. He has two local QMs, QM1 and QM2, in the same cluster as a remote QM3.
  2. His apps are connecting to QM1, using a user called 'mqm'.
  3. When he tries to put messages to cluster queues that are hosted on QM3, his messages are getting bounced (somehow) because QM3 does not know his user 'mqm'.
  4. When he tries to connect to his QM1 using a user called 'MQXXX', he is getting 2035 trying to connect, because his QM1 doesn't know a user called 'MQXXX'.

This is why I think he can fix his problem by defining a local user on QM1 named 'MQXXX', and granting that user sufficient access to QM1 for what he needs. Because then his messages will be going across the channel to QM3 as being from 'MQXXX' (even if it's a different MQXXX with a different password). This is a similar problem to authenticating a message created on a distributed QM to a QM on OS/390.

But this is just what I read. Maybe I'm interpreting what he's saying wrong, or missing some other detail.
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri Jan 23, 2004 11:59 am    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Jeff, the reason i said it wont work by adding a userid on the local node which is QM1 is because of the following reasons.

1) Deep under in one of Peter's posts he mentioned that his partner wanted to place this userid MQXXX in the MD. Which i would assume is the useridentifier. Now if it were md, then that would mean he is trying to do a PUT. Which would lead me to say that he has already successfully done the connect and the open. Thats precisely the reason i asked peter to explain in detail his scenario. We have gone this far even without knowing what api call is failing with 2035. :)
2) Any application would be able to connect to a local queue manager unless you are logged in as a userid that does not have access or have only limited access. Since Peter mentioned earlier that he was logged in as "mqm", i would expect he be able to connect to the qm. And since during connect you dont specify userids, it would use the logged on userid.
3) As for Mqopen, since this is a cluster queue, it would just do a lookup in the local cache and say yes, its fine. And this also should be fine. The only thing i am not sure of is what happens when you use alternate userid in mqopen of a cluster queue, as i already mentioned in my previous post. But again, defining a userid locally wont solve this problem because the cluster queue def in the cache cannot be setmqaut'd with this newly defined userid.

I know this is a MESS..... I should have been in some other field than MQ... LOL

So all in all we need more info to figure out what is going on. But above is my explaination of the possibilities.

Cheers
Kumar
Back to top
View user's profile Send private message Send e-mail Visit poster's website
peterw686
PostPosted: Fri Jan 23, 2004 12:00 pm    Post subject: Reply with quote

Acolyte

Joined: 26 Sep 2002
Posts: 73

Hi JeffLowrey,

You are right. This is exactly what the scenario and problem.

When I use "mqm", I can send the message to QM3. There must be a program logic to check the user id, if it's not "MQXXX", it will reply a error message to my dead letter queue. That's why I didn't get a MQ exception in this case.

My next question is:
Do I need to create a user "MQXXX" on QM1 and QM2's unix machine and login by that user to run the application?

Our application is host on the same box as MQ on unix and used same login user "mqm" to start application server (weblogic) because we want to bind JMS admin object of MQ.

Thanks for your help.
Back to top
View user's profile Send private message
peterw686
PostPosted: Fri Jan 23, 2004 12:18 pm    Post subject: Reply with quote

Acolyte

Joined: 26 Sep 2002
Posts: 73

Hi Kumar,

Sorry, I didn't see your comment before I reply to Jeff.

For
Quote:
2) Any application would be able to connect to a local queue manager unless you are logged in as a userid that does not have access or have only limited access. Since Peter mentioned earlier that he was logged in as "mqm", i would expect he be able to connect to the qm. And since during connect you dont specify userids, it would use the logged on userid.
, I don't understand "Any app would be able to connect to a local queue manager". During my local test shown in other thread http://www.mqseries.net/phpBB2/viewtopic.php?t=13052
if the local app specified a user id other than mqm or null ( in my case)during the call, it still doesn't have the access. That's why when I used "MQXXX" in my call and failed with 2035 error.
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri Jan 23, 2004 12:29 pm    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Peter if this is what was the cause of all this 2035 issue, then i guess we are solved here.

What you showed to me in the thread
http://www.mqseries.net/phpBB2/viewtopic.php?t=13052


is "NOT" a local app. It is a "CLIENT APP". And a client app is NOT local to the queue manager and hence you need to define a principal to grant access to it.

Since in any of your posts here you did not mention the entire scenario all assumptions were that you had a Server app(a server app is the one that is bound to server libraries and is local to the QM). But it looks like you are trying to connect using a Client app(a client app is the one that is bound to client libraries and is NOT local to QM). Which would explain the reason why you were getting 2035's as you mentioned in your other thread.

Hope this clarifies all the doubts and you are back on.

Cheers
Kumar
Back to top
View user's profile Send private message Send e-mail Visit poster's website
peterw686
PostPosted: Fri Jan 23, 2004 12:40 pm    Post subject: Reply with quote

Acolyte

Joined: 26 Sep 2002
Posts: 73

Hi Kumar,

Not exactly true.

Even though my test cases are running as client app connecting to remote server, I did test on Win2000 locally as well and I got the 2035 if I assign user id to something not exist in my local user group.

My NT login user is "peter" and I also have a user defined as "test". I have a MQ installed on NT as well.

During my local application call (exactly the same application tested in that thread, just change to call the local MQ Queue manager instead of remote call)

for
Quote:
MQEnvironment.userID = null
, or
Quote:
MQEnvironment.userID = "peter"
or
Quote:
MQEnvironment.userID = "test"
, all work fine. However, it doesn't work for
Quote:
MQEnvironment.userID = "userNotExist"
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri Jan 23, 2004 12:45 pm    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Ok... And now the issue is???

What you posted just now is another way of putting what you posted earlier in the other thread. Except that in this case you had a local qm and a local app as opposed to a client app and qm on server system.

Cheers
Kumar
Back to top
View user's profile Send private message Send e-mail Visit poster's website
peterw686
PostPosted: Fri Jan 23, 2004 1:10 pm    Post subject: Reply with quote

Acolyte

Joined: 26 Sep 2002
Posts: 73

Hi Kumar,

What I tried to point out is that no matter it's a client app call or a local app call, they both have to have the exist user id on server side.

I guess the solution now is like Jeff said to create a user on QM1 and QM2 with name "MQXXX". Thanks for your help.
Back to top
View user's profile Send private message
mqonnet
PostPosted: Fri Jan 23, 2004 1:14 pm    Post subject: Reply with quote

Grand Master

Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.

Peter, once again you did not carefully read my earlier posts.

"3) As for Mqopen, since this is a cluster queue, it would just do a lookup in the local cache and say yes, its fine. And this also should be fine. The only thing i am not sure of is what happens when you use alternate userid in mqopen of a cluster queue, as i already mentioned in my previous post. But again, defining a userid locally wont solve this problem because the cluster queue def in the cache cannot be setmqaut'd with this newly defined userid.
"

Try defining a local userid/principal on QM1 and post the results, i would be curious to know, per the above theory.

Again, i dont think this should make any difference. But trying never should be a problem.

Also its been so long that we have been discussing this and i have been asking you, you never told me. WHAT API CALL FAILS WITH 2035 when you run your app with userid MQXXX on QM1???


Cheers
Kumar
Back to top
View user's profile Send private message Send e-mail Visit poster's website
peterw686
PostPosted: Fri Jan 23, 2004 1:35 pm    Post subject: Reply with quote

Acolyte

Joined: 26 Sep 2002
Posts: 73

Yes, you are right, they may have cache problem. I will try on Monday and let you know the result.

I don't know exactly which MQ API was failed cause I am not a MQ guy.

The java API failed on
Code:
qcon = qconFactory.createQueueConnection("MQXXX", null);
Back to top
View user's profile Send private message
techno
PostPosted: Fri Jan 30, 2004 9:54 pm    Post subject: Reply with quote

Chevalier

Joined: 22 Jan 2003
Posts: 429

Why are we doig client connection here?

Does a program need to take care when Put fails (Because the qmgr name is hard-coded!)? is there anyway mq taking care of such failure because of clustering?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » Clustering » check remote cluster 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.