Issues with connecting to ibm mq 7.5 using java - java

I'm very new to ibm mq, I find out the documents or books related to mb are so few, the only one I found is 'WebSphere MQ Using Java' written in 2004. But the real world has changed a lot.
I installed and verified mq server 7.5 on redhat linux 64 bit successfully according to this
I also created queue manager myqm1, queue LQ.TEST, channel JAVA.CHANNEL and did some test through command lines on server to ensure they work well. However when I installed a mq client on windows xp and wrote below java code, it always throw a exception:com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'
my code:
import com.ibm.mq.*; import com.ibm.mq.constants.MQConstants;
/** * Simple example program */ public class MQSample {
// code identifier
static final String sccsid = "#(#) MQMBID sn=p000-L120604 su=_H-IvIK4nEeGko6IWl3MDhA pn=MQJavaSamples/wmqjava/MQSample.java";
// define the name of the QueueManager
private static final String qManager = "myqm1";
// and define the name of the Queue
private static final String qName = "LQ.TEST";
/**
* Main entry point
*
* #param args - command line arguments (ignored)
*/
public static void main(String args[]) {
try {
MQEnvironment.hostname = "58.2.221.196";
MQEnvironment.channel = "JAVA.CHANNEL";
MQEnvironment.port = 1414;
MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES);
MQEnvironment.userID = "mqm";
MQEnvironment.password = "mqm";
MQEnvironment.CCSID = 1208;
// Create a connection to the QueueManager
System.out.println("Connecting to queue manager: " + qManager);
MQQueueManager qMgr = new MQQueueManager(qManager);
// Set up the options on the queue we wish to open
int openOptions = MQConstants.MQOO_INPUT_AS_Q_DEF | MQConstants.MQOO_OUTPUT;
// Now specify the queue that we wish to open and the open options
System.out.println("Accessing queue: " + qName);
MQQueue queue = qMgr.accessQueue(qName, openOptions);
// Define a simple WebSphere MQ Message ...
MQMessage msg = new MQMessage();
// ... and write some text in UTF8 format
msg.writeUTF("Hello, World!");
// Specify the default put message options
MQPutMessageOptions pmo = new MQPutMessageOptions();
// Put the message to the queue
System.out.println("Sending a message...");
queue.put(msg, pmo);
// Now get the message back again. First define a WebSphere MQ
// message
// to receive the data
MQMessage rcvMessage = new MQMessage();
// Specify default get message options
MQGetMessageOptions gmo = new MQGetMessageOptions();
// Get the message off the queue.
System.out.println("...and getting the message back again");
queue.get(rcvMessage, gmo);
// And display the message text...
String msgText = rcvMessage.readUTF();
System.out.println("The message is: " + msgText);
// Close the queue
System.out.println("Closing the queue");
queue.close();
// Disconnect from the QueueManager
System.out.println("Disconnecting from the Queue Manager");
qMgr.disconnect();
System.out.println("Done!");
} catch (MQException ex) {
ex.printStackTrace();
System.out.println("A WebSphere MQ Error occured : Completion Code " + ex.completionCode
+ " Reason Code " + ex.reasonCode);
} catch (java.io.IOException ex) {
System.out.println("An IOException occured whilst writing to the message buffer: " + ex);
}
return;
} }
Can anybody throw a light to me on that? I'm totally down.

To expand on Shashi's answer, since WMQ V7.1 the default CHLAUTH rules block all access on all SVRCONN channels and they block administrative access on all SVRCONN channels. If you really want to connect to JAVA.CHANNEL as mqm then you will need to override both of these behaviors.
If you are actually willing to allow remote, unauthenticated connections to the QMgr with an administrative user ID, then you have the option of disabling CHLAUTH rules altogether. You can do this by issuing the ALTER QMGR CHLAUTH(DISABLED) command in runmqsc however this is HIGHLY discouraged because it leaves the QMgr open to anonymous remote code execution using the WMQ administrative user ID. This is, however, what you appear to be trying to do.
The recommended approach would be to use an ID that is not administrative. For example, if you made an ID called mquser with a private group also called mquser then you could grant it rights to connect and inquire on the QMgr and to open the designated queue for put, get, browse and inquire. Since the ID is not administrative, it would be relatively safe to use on unauthenticated channels. You could change your code to specify the ID as mquser instead of mqm and then use a CHLAUTH rule to allow the connection. For example:
SET CHLAUTH('JAVA.CHANNEL') TYPE(USERMAP) +
CLNTUSER('mquser') USERSRC(MAP) +
MCAUSER('mquser') ACTION(ADD)
The above rule tells the QMgr "when you see a connection from the mquser ID on JAVA.CHANNEL, then set MCAUSER to mquser and allow the connection."
When you grant permissions, remember to grant them on the group and not the user. For example, if using setmqaut use the -g option and not the -p option. If there are any issues with authorization errors, you can sort these out easily using event messages. First, enable events using the ALTER QMGR AUTHOREV(ENABLED). This will cause the QMgr to emit an event message into the SYSTEM.ADMIN.QMGR.EVENT queue. You can use SupportPac MH05 or SupportPac MS0P to parse the event messages. For any given authorization event the message tells you the ID that requested access, the API call (connect, open, close etc.), the object the call was made against and the exact options that were used.
Prior to WMQ V7.1, WebSphere MQ allowed all remote connections, even anonymous, administrative ones. Although this allowed you to connect easily, in today's more hostile network environment the ability to remotely and anonymously execute code on the QMgr's host server is seen as an unacceptable security risk. So now a new QMgr is set to not allow any remote administrative access by default. As the administrator this requires you to explicitly disable security to get the old behavior or to explicitly provision secure access.

In MQ v7.5, by default access to queue manager is blocked. You need to create channel authentication records for the channel you created, JAVA.CHANNEL to allow user to access queue manager. Please follow this link for more details on Channel Authentication Records

Related

JMSCode to send and receive messages one by one using Database

After I went to multiple sites and learned JMS I wrote a JMS standalone client to read messages from a database and send them one by one. I also want to receive message one by one message and then update the database.
I need to send a message to a queue and the other application using standard JMS which will consume a TextMessage and whose body will be read as an ISO-8859-1 string. Also they will similarly send reply as a TextMessage.
I wrote a for loop to read the message one by one from the DB.
I am new to JMS so could you please correct me whether my below code works properly to read and send messages to a queue and receive and update the DB. Is there any thing I need to change in the JMS Type or any thing I need to correct. Does the for loop work fine?
/*MQ Configuration*/
MQQueueConnectionFactory mqQueueConnectionFactory = new MQQueueConnectionFactory();
mqQueueConnectionFactory.setHostName(url);
mqQueueConnectionFactory.setChannel(channel);//communications link
mqQueueConnectionFactory.setPort(port);
mqQueueConnectionFactory.setQueueManager(qmgr);//service provider
mqQueueConnectionFactory.setTransportType(JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);
/*Create Connection */
QueueConnection queueConnection = mqQueueConnectionFactory.createQueueConnection();
queueConnection.start();
/*Create session */
QueueSession queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
/*Create response queue */
// Queue queue = queueSession.createQueue("QUEUE.RESPONSE");
int messageCount = 0;
Queue queue = queueSession.createQueue(replytoQueueName);
QueueSender queueSender = null;
QueueReceiver queueReceiver=null;
for (Testbean testBean : testbeanList) {
String testMessage = testBean.getMessage();
/*Create text message */
textMessage = queueSession.createTextMessage(testMessage);
logger.info("Text messages sent: " + messageCount);
textMessage.setJMSReplyTo(queue);
textMessage.setJMSType("mcd://xmlns");//message type
textMessage.setJMSExpiration(2*1000);//message expiration
textMessage.setJMSDeliveryMode(DeliveryMode.PERSISTENT); //message delivery mode either persistent or non-persistemnt
/*Create sender queue */
// QueueSender queueSender = queueSession.createSender(queueSession.createQueue("QUEUE.REQEST"));
queueSender = queueSession.createSender(queueSession.createQueue(outputQName));
queueSender.setTimeToLive(2*1000);
queueSender.send(textMessage);
/*After sending a message we get message id */
System.out.println("after sending a message we get message id "+ textMessage.getJMSMessageID());
String jmsCorrelationID = " JMSCorrelationID = '" + textMessage.getJMSMessageID() + "'";
/*Within the session we have to create queue reciver */
queueReceiver = queueSession.createReceiver(queue,jmsCorrelationID);
/*Receive the message from*/
Message message = queueReceiver.receive(60*1000);
// String responseMsg = ((TextMessage) message).getText();
byte[] by = ((TextMessage) message).getText().getBytes("ISO-8859-1");
logger.info(new String(by));
String responseMsg = new String(by,"UTF-8");
testDAO rmdao = new testDAO();
rmdao.updateTest(responseMsg, jmsCorrelationID);
messageCount += 1;
}
queueSender.close();
queueReceiver.close();
queueSession.close();
queueConnection.close();
Couple of things:
I would create your QueueSender and the Queue object its sending messages to outside the for loop since they don't appear to be changing.
Without the corresponding consumer code it's ultimately impossible to tell if the selector will work or not, but not invoking setCorrelationID() on the message you send looks a bit strange to me. Using the provider-assigned message ID may be a common pattern with IBM MQ request/reply applications, but the general pattern for using a correlation ID is to invoke setJMSCorrelationID() on the sent message. This makes the code more clear and also allows the application to directly control the uniqueness of the correlation ID. This is potentially important for application portability (e.g. if you migrated from IBM MQ to a different JMS provider) since different JMS providers use styles/formats of message ID specific to their particular implementation. Also, regarding the message ID the JMS spec states, "The exact scope of uniqueness is provider defined," which in my opinion is not a strong enough guarantee of uniqueness especially when using something like java.util.UUID.randomUUID().toString() is so simple.
You should ensure that you're using an XA transaction for both the JMS & database work so that they are atomic.
Close your JMS resources in a finally block.

Connecting to IBM MQ from Java client is failing with MQJE001: Completion Code '2', Reason '2035'

I have a IBM MQ version 7.5 installation in windows 7. I have created a queue manager, channel and listener using the following commands.
//CREATE THE QUEUE MANAGER
crtmqm.exe PG3RT1
//START THE QUEUE MANAGER AS INTERACTIVE
strmqm.exe -si PG3RT1
//CONNECT AS SCRIPT CONSOLE
runmqsc.exe PG3RT1
//CREATE THE CHANNEL TO APPLICATION CONNECTIVITY
DEFINE CHANNEL(PG3RT1.CHANNEL) CHLTYPE(SVRCONN) TRPTYPE(TCP)
//CREATE THE LISTENER
DEFINE LISTENER(LISTENER.PG3RT1) TRPTYPE(TCP) PORT(1414)
//START THE LISTENER
START LISTENER(LISTENER.PG3RT1)
Now i am trying to connect to the Queue Manager using following java client.
connection is rejected with the following error.
15:06:52.175 [localhost-startStop-1] ERROR c.b.c.s.s.m.MQUtil - MQJE001: Completion Code '2', Reason '2035'.
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:230)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553)
at com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at com.ibm.mq.StoredManagedConnection.<init>(StoredManagedConnection.java:96)
at com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:893)
at com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:780)
at com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:729)
at com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:177)
at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:745)
at com.bcs.cas.sach.simulator.mq.MQUtil.init(MQUtil.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
Can anyone advise why the connection is failing.
Do i need to enable remote administration on the queue manager?
Following is the code fragement i used for connection
public void init(){
MQEnvironment.hostname = hostName;
MQEnvironment.port = Integer.valueOf(port);
MQEnvironment.channel = serverChannelName;
MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES);
LOGGER.info("queueManagerName: " + queueManagerName);
LOGGER.info("hostName: " + hostName);
LOGGER.info("serverChannelName: " + serverChannelName);
LOGGER.info("port: " + port);
//initialize the connection pool
MQPoolToken token = MQEnvironment.addConnectionPoolToken();
try {
mqQueueManager = new MQQueueManager(queueManagerName, MQEnvironment.properties);
LOGGER.info("mqQueueManager: " + mqQueueManager);
} catch (MQException e) {
LOGGER.error(e.getMessage(), e);
}
}
MQRC 2035 is MQRC_NOT_AUTHORIZED. The reason this was returned can be found in the AMQERR log on the queue manager.
As CHLAUTH hasn't been configured, and is on by default, I expect you're not able to connect as you're not passing the CHLAUTH rules.
It is quite likely that this is an authorization issue. The easiest is to look at the return code and interpret
mqrc 2035 returns MQRC_NOT_AUTHORIZED
One of the reasons for it could be permissions. This can be resolved either by setting the right privilges on the QueueManager (setmqaut) , then on the channel enable the user with you are connecting to MQ to authorize as explained here . Post this you can use the code to connect by adding userId to the MQEnvironment and go
You can also refer this technote for information.
We are using clearing the authentication setting on manager by runmqsc:
SET CHLAUTH('CNL_NAME') TYPE(BLOCKUSER) USERLIST(ALLOWANY)
ALTER QMGR CONNAUTH(' ')
REFRESH SECURITY TYPE(CONNAUTH)
in case of development. Or proper setting of credentials:
QueueConnectionFactory.createQueueConnection(props.get(PROP.USER), props.get(PROP.PASSWD));
for JMS or:
...
MQEnvironment.userID = uid;
MQEnvironment.password = passwd;
new MQQueueManager(isQueueMgr);
for native com.ibm.mq.MQQueueManager.

How do you set a message selector using Java API?

I'm trying to write a simple test case to pull messages from a queue based on a message property, hitting a 7.5.0.3 QMgr and using the 7.5.0.3 client jars.
Everything I have seen online says that I need to specify the message selector when I open the queue. I'm fine with that, but I only see two ways to open it:
MQQueueManager.accessQueue(
String queueName,
int openOptions);
MQQueueManager.accessQueue(
String queueName,
int openOptions,
String queueMgr,
String dynamicQueueName,
String altUserId);
Neither of these allow me to specify a message selector. I'm running this from a command line batch application, not in an app server, so using JMS selectors is not possible.
Here is the IBM documentation on selectors: WebSphere MQ Message Selectors which shows that selection must happen as part of the MQOPEN call.
MQ JMS API provides the type of message selection syntax you are looking for. The base MQ Java API provides message selection based on MessageId and CorrelationId and it does not yet provide type selection syntax you are looking for. The documentation link you provided is for MQ C API.
Using MQ JMS API, message selection can be done as shown here:
// Create JMS objects
connection = cf.createConnection();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
// Create queue destination
Destination queDest= session.createQueue(que);
// Create consumer with selector
String selector = "category='bucket1'";
MessageConsumer cons= session.createConsumer(queDest, selector);
connection.start();
// receive messages
Message inMessage = cons.receive(5000);
You should specify selector when trying to read message from queue, like below:
MQMessage ResponseMsg = new MQMessage();
ResponseMsg.correlationId = CorrelationId;
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options = MQConstants.MQGMO_WAIT;
gmo.waitInterval = WaitTime * 1000;
gmo.matchOptions = MQConstants.MQMO_MATCH_CORREL_ID;
ResponseQueue.get(ResponseMsg, gmo);

Migration from mq version 7.0 to 7.5

I am Migrating from Mq version 7.0 to 7.5 . I am able to receive messages through the inbound queues using ejb - Message Driven Beans(MDBs) but while posting the message after processing it on the. I am getting the IBM MQRC 2082 MQRC_UNKOWN_ALIAS_BASE_Q Exception.
This is the exception that I am getting :
Caused by: javax.jms.InvalidDestinationException: MQJMS2008: failed to
open MQ queue 'OFS.TIG_IND2NSE_MSG'.
at com.ibm.msg.client.wmq.v6.jms.internal.MQQueueServices.getQueueOpenException(MQQueueServices.java:901)
at com.ibm.msg.client.wmq.v6.jms.internal.MQQueueServices.getOutputQueue(MQQueueServices.java:727)
at com.ibm.msg.client.wmq.v6.jms.internal.JMSServicesMgr.getOutputQueue(JMSServicesMgr.java:210)
at com.ibm.msg.client.wmq.v6.jms.internal.MQSession.createQProducer(MQSession.java:3138)
at com.ibm.msg.client.wmq.v6.jms.internal.MQSession.createProducer(MQSession.java:2863)
at com.ibm.msg.client.wmq.v6.jms.internal.MQSession.createProducer(MQSession.java:2920)
at com.ibm.msg.client.jms.internal.JmsSessionImpl.createProducer(JmsSessionImpl.java:1191)
at com.ibm.msg.client.jms.internal.JmsXAQueueSessionImpl$1.createSender(JmsXAQueueSessionImpl.java:415)
at com.ibm.mq.jms.MQQueueSession.createSender(MQQueueSession.java:148)
at weblogic.deployment.jms.WrappedSession.createSender(WrappedSession.java:344)
at com.tiger.gmfs.framework.jms.QUtil.getSender(QUtil.java:216)
at com.tiger.gmfs.framework.jms.QUtil.sendMessage(QUtil.java:110)
The piece of code that i wrote is :
this is my getSender method:
protected QueueSender getSender() throws JavaMessagingException,
JMSException {
QueueSender sender = null;
queue = qsess.createQueue(qVO.getName());
sender = qsess.createSender(queue);
if (sender == null)
throw new JavaMessagingException("The queue sender is null.");
sender.setPriority(qVO.getPriority());
return sender;
}
and this is my sendMessage method:
public void sendMessage(Message jmsMessage) throws JavaMessagingException,
JMSException {
QueueSender sender = null;
try {
sender = getSender();
sender.send(jmsMessage);
} catch (JMSException j) {
Exception l = j.getLinkedException();
if (l != null) {
JavaMessagingException be = new JavaMessagingException(
"JMSErrCode:" + l + " Code:" + j.getErrorCode()
+ " Message: " + jmsMessage, j);
throw be;
} else
throw new JavaMessagingException(j);
}catch(Exception e1){
System.out.println(e1);
}finally {
if (sender != null) {
sender.close();
TracingHelper.infoLog(QUtil.class, "sendMessage",
"Closed sender");
}
}
}
What changes should i do here that my code works?
I have Implemented the same code in jre 1.7 +weblogic 12c that works perfectly but when i changed it to jre 1.6 + weblogic 11g, i get this error.
From a development point of view, when an application opens the queue - the developer has to make sure that the right open options are used to open a WebSphere MQ queue.
If the application wants to put a message, open the queue with MQOO_OUTPUT open option and not any of the MQOO_INPUT* options.
If the application wants to get a message, open the queue with any one of the below open options, but not all at the same time
MQOO_INPUT_SHARED
MQOO_INPUT_EXCLUSIVE
MQOO_INPUT_AS_Q_DEF
The reason being, if the queue being opened is an alias queue pointing to a base queue in the same queue manager where the alias queue is present, and the base queue is a local queue - both, the OUTPUT and INPUT open options are valid.
However, if the alias queue being opened is pointing to a remote queue or a topic in the same queue manager where the alias queue is present, or if the alias queue is pointing to a cluster local queue present in a different queue manager in the cluster, all of the MQOO_INPUT* open options are invalid in this scenario.
Hence it is always advisable to open a WebSphere MQ queue only and only with the appropriate open options required for the operation being performed.
In your case, if you are trying to open the alias queue with any of the MQOO_INPUT* open option, and it is pointing to a cluster local queue in a different queue manager, it is incorrect. You have to remove the MQOO_INPUT* open option from your code to resolve the issue, as the MQOO_INPUT* option is not valid in this scenario.
MQRC 2082 MQRC_UNKOWN_ALIAS_BASE_Q is telling you that the queue in question:-
MQJMS2008: failed to open MQ queue 'OFS.TIG_IND2NSE_MSG'.
is an alias queue that isn't defined correctly, because the base queue it is pointing at doesn't exist.
Suggest you use the following MQSC command to display it:-
DISPLAY QALIAS(OFS.TIG_IND2NSE_MSG) ALL
and look for the field TARGET, and then issue another MQSC command to display the queue it is aliasing:-
DISPLAY QUEUE(target-queue-name) ALL
which I expect will fail telling you the queue doesn't exist. In that case you should either define it, or correct the QALIAS definition to point at the correct target queue name.
The Problem is for an alias when the Base Queue Manager is present at the cluster or some other Remote Queue manager. setting the Queuemanger name explicitly will give this error.
if(jmsConfigQueue.getOpenOptions()!=null){
if(jmsConfigQueue.getOpenOptions().equalsIgnoreCase("Inbound"))
{
mqqueue.setBaseQueueManagerName(qcf.getQueueManager());
}
else if(jmsConfigQueue.getOpenOptions().equalsIgnoreCase("Outbound"))
{
mqqueue.setBaseQueueManagerName("");
}
else
mqqueue.setBaseQueueManagerName(qcf.getQueueManager());
}
else {
mqqueue.setBaseQueueManagerName(qcf.getQueueManager());
}
So to enable the application search the Base Queue Manager(Remote) set it as blank. as the above code.

DetailedJMSSecurityException while trying to access queue in IBM MQ

Here is my problem.
I am using trial version of IBM MQ V7.1. I have created a queue manager MYQM, a channel MY_SVRCONN with MCA User Id abc. I have provided user abc to access MYQM. I am trying to put a message into the queue Q1. But while getting the queue connection i am getting below exception.
com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQM' with connection mode 'Client' and host name '(1500)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.
I have used below command to allow user abc to access MYQM.
[mqm#localhost ~]$ setmqaut -m MYQM -t qmgr -p abc +connect
The setmqaut command completed successfully.
Here is my Java program
public class MqPut
{
public static void main(String[] args)
{
sendMsg("Sample Message");
}
public static void sendMsg(String msg)
{
MQQueueConnectionFactory connectionFactory = null;
QueueConnection queueConn = null;
QueueSession queueSession = null;
QueueSender queueSender = null;
TextMessage message = null;
try
{
connectionFactory = new MQQueueConnectionFactory();
connectionFactory.setHostName(<MQ SERVER IP>);
connectionFactory.setPort(1500);
connectionFactory.setTransportType(WMQConstants.WMQ_CLIENT_NONJMS_MQ);
connectionFactory.setQueueManager("MYQM");
connectionFactory.setChannel("MY_SVRCONN");
queueConn = connectionFactory.createQueueConnection("abc","password");
queueSession = queueConn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
queueSender = queueSession.createSender(queueSession.createQueue("Q"));
queueSender.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
message = queueSession.createTextMessage(msg);
queueSender.send(message);
queueConn.close();
}
catch (Exception je)
{
je.printStackTrace();
}
}
}
I have tried with WebSphere 7, configuring JMS Q connection factory without user id: MQRC_NOT_AUTHORIZED, but still my problem persist. I am not getting what I am doing wrong. Any help is appreciated.
EDIT
User abc is not part of mqm group
Have you set chlauth (channel authentication) for the user on the svrconn channel? Channel authentication is new from MQ 7.1 onwards. The password validation is available from MQ 8 only. Basically you need to allow the remote connections from your client IP on the qmgr svrconn channel.
try in the mqsc console
SET CHLAUTH(MY_SVRCONN) TYPE(ADDRESSMAP) ADDRESS(ip of the client machine) USERSRC(CHANNEL)
If this doesnt work, check the qmgr log. It should exactly say what is causing the 2035.
A good technote is found here http://www-01.ibm.com/support/docview.wss?uid=swg21577137
Morag's really useful blog https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/blocked_by_chlauth_why?lang=en
In a development environment (WMQ 8.0), I prefer to modify the authorization so that it is optional.
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
(Disabling this feature is not recommended for production queue managers due to security implications.)
In WMQ 7.1, it's possible to set channel authorization to be disabled, but that does not appear to work on WMQ 8.0
ALTER QMGR CHLAUTH(DISABLED)
Whenever you get any error back from a queue manager, remember that you should always look in the queue manager AMQERR01.LOG for a more detailed explanation. This is especially true for any security related error, since only a single error code - MQRC_NOT_AUTHORIZED (2035) - which is translated into JMS Exception JMSWMQ2013 - is returned to the application so as to not give away the details why to any potential hacker. You must always look at the queue manager error log for the details.

Categories