I written a Java MQ client to write and read message after went to multiple sites learned a bit about MQ. When I run the client code it given error as below:
MQJE001: Completion Code '2', Reason '2540'.
I put a log statement in and it shows Exception in the below place
private void selectQMgr() throws MQException {
logger.info("qMgrName in selectQMgr method: "+ qMgrName);
qMgr = new MQQueueManager(qMgrName, mqht);
mqht is Hashtable reference which contains the Host Name,Port and channel propery which I passed from script.
My system has v 7.5 MQ client and I used all the required jars for compile and run.
Also I went to /opt/mqm/samp/bin and run the below command
• $ amqsput TESTQ QMGR
• Sample AMQSPUT0 start
• MQCONN ended with reason code 2058
• $ MQCONN ended with reason code 2058
it given above error not sure whether I am trying correct or not.
I am new to MQ and bit confused after I read from the IBM site mentioned as below:
• Queue-manager groups are not supported.
• There is no queue-manager group with the specified name.
All the Required properties for MQ connection got from Support team not sure what is the issue. Is it my system not connecting or not.
Please help on this. Thanks in Advance
There are 2 types of connection models:
Bindings mode - when an application connects to a queue manager in bindings mode, the application MUST be running on the same server as the queue manager. The application also does NOT specify the host, port # and channel name.
Client mode - means that the application MUST specify the host, port # and channel name because the application is NOT on the same server as the queue manager.
$ amqsput TESTQ QMGR
IBM has a naming standard for executable files:
If the executable file does NOT end with 'c' (i.e. amqsput) then it is is compiled and linked for bindings mode. i.e. local queue manager
If the executable file DOES end with 'c' (i.e. amqsputc) then it is is compiled and linked for client mode. Hence, you need to use either a CCDT file by setting MQCHLLIB & MQCHLTAB environment variables or set the MQSERVER environment variable.
Now on the remote server, there can be 1 or more queue managers running. Each queue manager will have its own MQ listener listening on a port. i.e. 1414. If there are 3 queue managers running on the server then the ports used could be 1414, 1415 & 1416 or 14001, 14002 & 14003. You will need to ask your MQAdmin for the correct port number for that particular queue manager.
Reason Code of 2540 (MQRC_UNKNOWN_CHANNEL_NAME) means that you are using a channel name that is NOT defined on the queue manager. Note: All objects are case sensitive. i.e. "Test.Chl" is not the same as "TEST.CHL". Also, bookmark the MQ Reason Code page because it is something you will need to reference often.
Finally, since you are new to MQ, I would strongly suggest you attend MQ Technical Conference (MQTC). MQTC is the largest conference in the world solely dedicated to IBM MQ. It is 3 days of technical training at a super cheap price.
Related
I'm trying to setup a Client connection to IBM MQ and test this using the samples application wmqjava.
I am able to connect in binding mode but I'm getting a 2035 unauthorised error when using client mode.
The steps I've taken to set this up are:
Create / run a queue manager
Create a listener
Create a SVRConn channel (multiple attempts)
I think I'm missing something with authorisation?
DEF CHL('TEST2.CHANNEL') CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER(' ')
I'm trying to connect to this on the same machine that the MQ server is running on.
Depending on the version of IBM MQ you are using, you could be being blocked by the default CHLAUTH rule which bans client connections which assert privileged user ids, or the default CONNAUTH rule which demands a password is provided for such a client connection.
Read Getting going without turning off MQ Security for instructions on how to turn both off, or use both correctly.
FYI: Your queue manager error log will tell you the reason you were blocked from accessing it.
You can put the user "mqm" in MCAUSER Field to bypass all the authorisation.
DEF CHL('TEST2.CHANNEL') CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('mqm')
This will use all the authorities of mqm user (Default MQ admin user) to connect to Queue Manager.
Alternatively you can authorize the user to allow to connect, put, get messages.
setmqauth or getmqauth commands can help you.
I am unable to connect IBM websphere MQ
Can anyone tell me what are the initial setting need to be done in MQ to acces it from remote machine using simple java code?
Besides the MQ samples shipped with the product, there is also a long list of Java & Java/JMS samples here.
The recommended practice for MQ Java (non-JMS) is:
Hashtable mqht = new Hashtable();
mqht.put(CMQC.CHANNEL_PROPERTY, channelName);
mqht.put(CMQC.HOST_NAME_PROPERTY, hostName);
mqht.put(CMQC.PORT_PROPERTY, new Integer(portNumber));
try
{
MQQueueManager qMgr = new MQQueueManager(qMgrName, mqht);
System.out.println("Successfully connected to "+ qMgrName);
}
catch (com.ibm.mq.MQException mqex)
{
System.out.println("MQException cc=" +mqex.completionCode + " : rc=" + mqex.reasonCode);
}
A few points to make sure you are able to connect to Websphere MQ using Java code :
Have you validated your MQ server deployment using these steps "Verifying Installation" in following deployment instructions http://sadockobeth.blogspot.in/2014/03/how-to-install-ibm-websphere-mq-75-on.html
Have you started a listener for a Queue Manager that is configured on your MQ server. You can find command to start Listener here http://bencane.com/2013/04/22/websphere-mq-cheat-sheet-for-system-administrators/
With default installation the connection from a Java application over TCP will fail because of channel authentication enforced by default. You can confirm this is the case by looking at Queue manager error logs. Would suggest you to look at appropriate ways to configure channel authentication to allow the Java application to connect. One method ok for Non-Production or test set up is to disable channel (Please use this with caution).
If all of the above are taken care and still you are not able to connect than you will need to look at your Java client code and get more information from error codes that your code is seeing. If there are any genuine network connectivity issues or some thing else like firewall preventing connection etc.
I'm using RAD 9.0 and trying to configure Queue connection factories in WebSphere Application Server 8.5. I have IBM MQ 7.0 (32-bit) installed on the same machine (Win7 64-bit).
After configuring Queue connection factories when I click on Test Connection it give an error :
A connection could not be made to WebSphere MQ for the following reason: CC=2;RC=2495;AMQ8568: The native JNI library 'mqjbnd' was not found. For a client installation this is expected. [3=mqjbnd]
Native library path (under JMS>WebSphere MQ messeging provider) is set to C:/Program Files (x86)/IBM/WebSphere MQ\java\lib.
I also tried to set it to C:/Program Files (x86)/IBM/WebSphere MQ\java\lib64 but still I'm getting the same error.
Also is it necessary to configure Queue Connection Factory for configuring Listener Port for MDB?
The error message means you have configured the connection factory to have a transport type of Bindings and so the WMQ Resource Adapter within WAS needs to load the native libraries located in the MQ installation (note the MQ client installation does not come with these libraries).
Assuming you want to connect in Bindings mode AND you have a full local MQ Server installation on the same box as the WAS server then you will need to configure the 'Native Library Path' on the WebSphere MQ messaging provider panel in WAS (Resources > JMS > JMS Providers). You should alter the provider that is at the same scope as the defined queue connection factory.
The MQ_INSTALL_ROOT property is an old property used in WAS 6.0 and WAS 6.1 and is only intended to be used for migration reasons in WAS 7 and onwards.
Note: If you have an ND environment then the 'Test Connection' operation could potentially run on the dMgr process rather than the server. If your dMgr is on a different host then the libraries will not be found. In this case you should ensure that the application server is running before selecting the 'Test Connection' button.
WAS uses environment variable MQ_INSTALL_ROOT to point to (embedded) WebSphereMQ Client (Environment->WebSphere Variables). Default value is ${WAS_INSTALL_ROOT}/lib/WMQ. I think you don't need a separate installation of WebSphereMQ client - it comes with WAS (I'm working with WAS8, but I guess they did not change it in 8.5).
As for your question, it might be the issue with the path: it uses spaces. Try to install WebSphereMQ client libs in a directory without spaces (e.g. C:\IBM\WMQClient). But I think you do not need it, check directory ${WAS_INSTALL_ROOT}/lib/WMQ - it should be there.
And about Activation Specification - you don't need Queue Connection Factory, you need only queue definition where Activation Specification will connect to.
I am on websphere v7.0 and websphere mq 6. while trying to connect to queue manager through websphere console i am getting compcode '2' ('MQCC_FAILED') reason '2058' error.The queue manager with the same is available on the mq server with the server channel defined.
Any help much Appreciated.
MQRC_Q_MGR_NAME_ERROR (2058) is a generic error (This has been improved in the latest version of wmq). There could be a problem with the host name or its resolution, the port or even the channel name or qmgr name. Look closely for errors. Is there anything reported in /var/mqm/errors on the websphere 7 server?
If you are making use of a Client Channel Definition Table (CCDT) then this can imply that the queue manager name you used on MQCONN in your application, has not been found as QMNAME on any CLNTCONN channel in your CCDT. This can sometimes just mean that the CCDT has not been found at all.
Of course, sometimes this all just means that you meant to set MQSERVER to something and your forgot, so then the MQ Client goes looking for a CCDT instead and doesn't find one of those either.
I received the same error. Couple of things to try based on my debugging session.
Check QueueManager name. Note that it is case-sensitive. I had it in lower case in my python script. As soon as I put QueueManager name in capital letters. It worked.
Check if Queue host name is mentioned correctly. Queue manager name and Queue host name are different.
Check if you are able to telnet host on the port you are trying to access queue.
Restart Queue Manager.
Restart app server from where you are trying to connect.
Check if connection channel is mentioned correctly.
Check if queue name or queue Alias name are mentioned correctly.
I need to write a simple MQSeries client in Java.
The client just has to connect to the queue and pull off the next message.
I have done this before a number of years ago and have all the sample code etc.
All I remember needing are the three jar files:
com.ibm.mq.iiop.jar
com.ibm.mq.jar
connector.jar
I have been doing some reading and a lot of people talk about a properties file, but I have no recollection of this from my past experience.
And so on to my question:
What is the absolute minimum I need on my system to develop, test and ultimately deploy a simple MQSeries client?
And where can I find (download) these things?
NOTE: This question is related to but not the same as this one.
The answer to the question depends on whether you want to put the resulting code into Production. You can grab a few jar files and include them on the CLASSPATH and get it to work. In fact with the repackaging done in v7, the number of jars has been reduced. However, it is not supported by IBM without the full client install.
Why is that? The full install includes diagnostic facilities, supporting code, NLS support and the ability to collect all the Must Gather information to open a trouble ticket. If all you grab is a few jar files, you do not get the additional functionality and therefore no vendor support if something goes wrong.
The WMQ v7 client install provided as SupportPac MQC7 which is a free download.
The jar files and CLASSPATH settings for both base Java and JMS are provided in the Using Java manual.
Use the v7 client, even on a v6 server. It's backward compatible. In v7.0 the Java/JMS has all been rewritten and you just need the jars listed in the manual.
Also, someone mentioned the etclient jar. That's the Extended Transactional Client and please be aware that it incurs the full license cost of a QMgr. You only need it if you are doing 2-phase commit (XA with WMQ and another resource manager in the same unit of work) and not using WebSphere App Server or Message Broker. For example, you want to do TPC using JBoss, MQ and a database, you need etclient jar file and pay for a full WMQ license. If you are not doing XA transactions you don't need it.
Here is another way...
Using the three jar files:
com.ibm.mq.jar
com.ibm.mqetclient.jar
com.ibm.mqjms.jar
Here is a code sample that will read an MQ message -
import com.ibm.mq.*; // Include the WebSphere MQ classes for Java package
public class MQSample
{
private String qManager = "your_Q_manager"; // define name of queue
// manager to connect to.
private MQQueueManager qMgr; // define a queue manager
// object
public static void main(String args[]) {
new MQSample();
}
public MQSample() {
try {
// Create a connection to the queue manager
qMgr = new MQQueueManager(qManager);
// Set up the options on the queue we wish to open...
// Note. All WebSphere MQ Options are prefixed with MQC in Java.
int openOptions = MQC.MQOO_INPUT_AS_Q_DEF |
MQC.MQOO_OUTPUT ;
// Now specify the queue that we wish to open,
// and the open options...
MQQueue system_default_local_queue =
qMgr.accessQueue("SYSTEM.DEFAULT.LOCAL.QUEUE",
openOptions);
// Define a WebSphere MQ message buffer to receive the message into..
MQMessage retrievedMessage = new MQMessage();
// Set the get message options...
MQGetMessageOptions gmo = new MQGetMessageOptions(); // accept the defaults
// same as MQGMO_DEFAULT
// get the message off the queue...
system_default_local_queue.get(retrievedMessage, gmo);
// And prove we have the message by displaying the UTF message text
String msgText = retrievedMessage.readUTF();
System.out.println("The message is: " + msgText);
// Close the queue...
system_default_local_queue.close();
// Disconnect from the queue manager
qMgr.disconnect();
}
// If an error has occurred in the above, try to identify what went wrong
// Was it a WebSphere MQ error?
catch (MQException ex)
{
System.out.println("A WebSphere MQ error occurred : Completion code " +
ex.completionCode + " Reason code " + ex.reasonCode);
}
// Was it a Java buffer space error?
catch (java.io.IOException ex)
{
System.out.println("An error occurred whilst writing to the message buffer: " + ex);
}
}
} // end of sample
Code taken from this SO answer.
Ok it looks like you need the three jars I mentioned in the question as well as a properties file.
com.ibm.mq.iiop.jar
com.ibm.mq.jar
connector.jar
mqji.properties
Unless you have access to these things already the only way I could figure out to get them was to download and install the FULL trial version for MQSeries from IBM:
http://www.ibm.com/developerworks/downloads/ws/wmq/
If that link dies over time you can also find it by just going to www.ibm.com and then following the menu from "Support & Downloads" -> "Download" -> "Trials and demos" and then choosing "WebSphere MQ" from the list.
Once the install is done, you have all the jars you need in the java/lib folder below where the installation happened. The Jars in this version are different from the jars I mention above, I suspect because of version differences.
The properties file was not installed with the install (perhaps the new versions does not need this file), but it can be found here.
Its been a while since I did this too, IBM provides java api for directly using mqseries and JMS api too that is a wrapper around it.
Go here, they have many examples in java http://www304.ibm.com/jct01005c/isv/tech/sampmq.html
For testing, you will need to download and setup a MQseries Server, or maybe they will be kind enough to set you up with a test queue on the real server.
In anycase, when you download the MQseries server from the IBM's website (trial lic) that should contain the jar's you need.
I would strongly research into the JMS api for MQSeries, so that you can stay away from actually using the mqseries api.