Link to home
Start Free TrialLog in
Avatar of buckrodger
buckrodger

asked on

MQ logging

I'm an MQ newb. I'm trying to connect from WAS7 JMS. I use JNDI to get the QueueConnectionFactory then call createQueueConnection. When I make this call I get a JMSException caused by

JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED')

I would like to see the credentials being passed to MQ, does MQ log failed connection attempts ? Is there a way to see why this connection is failing ?

thanks very much
Avatar of HonorGod
HonorGod
Flag of United States of America image

It looks like you are getting an authorization failure (e.g., bad userid/password kind of thing).

Information about "API Completion and reason codes" can be found here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqsao.doc/csq0519.htm

Information about "Security consideration" can be found here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqtac.doc/wq10400_.htm

Is this a new installation, or did you upgrade your MQ and/or WSAS recently?

Did it ever work?

Are they (MQ & WSAS) on the same, or different machines?

Searching for MQRC_NOT_AUTHORIZED, we find:
--------------------------------------------------
MQRC_NOT_AUTHORIZED

public final static int

Reason code - queue is not authorized for access.
--------------------------------------------------

Information about "Log defaults" can be found here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12570_.htm

Hopefully this helps.

Let me know.
Avatar of buckrodger
buckrodger

ASKER

We did upgrade WAS from 6.1 to 7.  And this all worked on 6.1.  In my local env WAS and MQ are on different machines.  In the test env WAS and MQ are on the same machine.  I don't think its a password thing because if I specify the same username and password on the createQueueConnection call it works fine.  However if I let WAS pass the credentials it fails.
So what version of MQ is being used?  6.0, I presume.
6.0.2.6
Here's something that I just learned:

changes were done to the MQ JMS V7 client to provide to the MQ server the userid of the process (application) that is talking with the MQ server via the MQ JMS client.
In this case, the MQ queue manager has received a username which either:
- Does not exist in the Unix host of the MQ queue manager,
- Does exist, but it does not have the proper authority to access the MQ queue manager.

Solution
Check which user ID the application is being run under and then check to see if that user ID is in the mqm group (or some other group with sufficient authority).
If it is not in the mqm group, then add it to the mqm group and issue a runmqsc  command:
REFRESH SECURITY(*)

The user ID associated with the program when it runs must have authority to access certain resources of the queue manager. Grant the following authorities to the user ID:
- The authority to connect to the queue manager, and the authority to inquireon the attributes of the queue manager object
- The authority to put and get messages on the desired queue.
.
b) In case that it is not obvious which is the actual userid token that is received by the MQ queue manager from the MQ JMS client, then it is necessary to take a trace of the queue manager (and if possible, a trace of the MQ JMS client).
The tokens to look for in the traces are:
+ From the JMS Trace (trace.log) you can see the userid that is sent by the MQ Client
For example, the trace.log for the JMS client may have strings such as these:

com.ibm.mq.jms.MQQueueConnectionFactory connecting as user: JohnDoe
com.ibm.mq.jms.MQQueueConnection Setting username = JohnDoe
com.ibm.mq.MQv6InternalCommunications userID = 'JohnDoe '
com.ibm.mq.MQv6InternalCommunications UID :JOHNDOE

+ From the MQ server trace you can see the userid that is received by the queue manager
It is very likely that one of the MQ trace files (*.FMT) will have the following string indicating that the value (username) is not a user ID in the system or that it does not belong to the mqm group (unknown principal). Search for the string: UnknownPrincipal

      UnknownPrincipal(johndoe)

Also, in case that the userid does exist, another possible cause is that the user does not have all the proper authorizations, thus, check for the following phrase in the trace:

      The following requested permissions are unauthorized:

I hope that this helps!
ASKER CERTIFIED SOLUTION
Avatar of HonorGod
HonorGod
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for your help
Glad to have been able to help.

Thanks for the grade & points.

Good luck & have a great day.