I'm very new to IBM MQ and feel like I'm missing something fairly easy.
I received the following files and I'm attempting to connect to an externally hosted MQ:
.crl
.kdb
.rdb
.sth
.tab
I've tried several different approaches, but the "furthest" I think I've gotten is:
MQRC_CONNECTION_BROKEN Reason: 2009 when I attempt to create a new Queue Manager connection.
Below is my most recent block of code, trying to get this to work:
using IBM.WMQ;
...
Hashtable connectionProperties = new Hashtable();
connectionProperties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
connectionProperties.Add(MQC.HOST_NAME_PROPERTY, SOME_ADDRESS);
connectionProperties.Add(MQC.CHANNEL_PROPERTY, SOME_CHANNEL);
connectionProperties.Add(MQC.PORT_PROPERTY, SOME_PORT);
connectionProperties.Add(MQC.SSL_CERT_STORE_PROPERTY, PATH TO KDB FILE without .kdb);
connectionProperties.Add(MQC.SSL_CIPHER_SUITE_PROPERTY, SOME_CIPHER);
MQQueueManager qmgr = new MQQueueManager(SOME_VALUE, connectionProperties);
Prior to this I was attempting to set the MQ_CHANNEL_LIB and MQ_CHANNEL_TAB environment variables and call MQQueueManager qmgre = MQQueueManager() but that resulted in a 2277 error code.
I'm currently using the IBMMQDotnetClient/9.3.0 nuget package. Any help would be greatly appreciated.
The *.kdb file is a ssl keystore file containing certificates required to connect to queue manager. The *.kdb file can only be used with Transport type (TRANSPORT_PROPERTY property) MQC.TRANSPORT_MQSERIES_CLIENT. In this mode, MQ .NET client uses MQI C client underneath to communicate with queue manager.
The *.tab file is a client channel definition table (CCDT) file containing connection information like qm name, channel name, host name and few others required to connect to your queue manager.
Since you are using IBMMQDotnetClient/9.3.0 nuget package, TRANSPORT_MQSERIES_CLIENT transport type can't be used as the package doesn't contain MQI C client. With this nuget package you can only use TRANSPORT_MQSERIES_MANAGED. Ask your admins/management if they can provide you Redistributable MQ client. This package contains MQI C, .NET and other MQ clients libraries. You can choose to install the client libraries you want to use.
As Shashi mentioned if you need to use the Unmanaged mode,you need MQ C Client libraries as well.
You need to reference "amqmdnet.dll" which comes with IBM MQ Redistributable package to your .NET project. You can download IBM MQ Redistributable package from IBM Fix central.
To use CCDT, you need to set MQCHLLIB & MQCHLTAB environment variables.On how to create a CCDT file you can refer KC page:Configuring a binary format CCDT
After creating the CCDT File, i had used only the following code in my project to establish a successful connection
Environment.SetEnvironmentVariable("MQCHLLIB", #"C:\ProgramData\IBM\MQ\qmgrs\QMSSL\#ipcc");
Environment.SetEnvironmentVariable("MQCHLTAB", "AMQCLCHL.TAB");
Hashtable properties = new Hashtable();
properties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
Environment.SetEnvironmentVariable("MQSSLKEYR", #"C:\temp\Certs\ForCclient\client");
try
{
queueManager = new MQQueueManager(queueManagerName, properties);
}
catch (MQException e)
{
Console.WriteLine("ERROR - Connect failed with unexpected MQRC {0}", e.ReasonCode);
throw e;
}
Related
Based on IBM MQ doc, I need to define a environment variable named MQSERVER for the MQ server address. So in one process, can I only have one MQ server address, is it correct?
Is there any other way to define MQ server address and have multiple MQ connections to different MQ servers?
You can specify the channel name, host, and port in the MQCD which is referenced from the MQCNO. In C you would pass this to the MQCONNX function.
You can also specify connection details (channel name, host, and port) in a CCDT (Client Channel Definition Table). You would point to the CCDT with the following environment variables (there are other ways but this is one way):
MQCHLLIB=/path/to/table
MQCHLTAB=table_filename.TAB
You could then use MQCONN (or MQCONNX) and specify just the queue manager name. MQ will find an entry in the CCDT that matches the queue manager name and use the connection details provided.
You specify the channel name, host, and port in the MQCD which is referenced from the MQCNO. In C it is the MQCONNX call that allows this. If you specify things in the CCDT then you point to the CCDT with MQCHLLIB=/path/to/table and MQCHLTAB=table_filename.TAB, then you can issue a normal MQCONN (or MQCONNX) call and specify just the queue manager name. It will find this QMNAME in the CCDT and use the connection details provided in the CCDT. – JoshMc 21 mins ago
I create a queue manager like QMTEST in IBM WebSphere MQ Explorer. I want to connect to a remote queue manager (remote ip address). I followed these steps:
add remote Queue manager
Queue manager name: QMTEST [Next]
Host Name or ip Address: X.X.X.X(remote ip) [Finish]
But I couldn't connect. I got this error message 'Could not establish connection to the queue manager-reason 2538.(AMQ4059)'. What can I do?
The four digit number in your error message is an MQRC (MQ Reason Code). This number gives you more information about what went wrong. You can look it up in Knowledge Center.
MQRC_HOST_NOT_AVAILABLE (2538)
There is a list of possible things that could cause this error. My guess is it is likely to be the first one, you have not started a listener on the queue manager, since you do not mention doing that in your question details.
You should also read the following link which is some basic details on how to connect to a remote queue manager. You appear to have the MQ Explorer side sorted, but perhaps not the queue manager side.
Setting up the server using the command line
Please ensure the listener is running on the remote queue manager side. The default MQ listener port is 1414. If the listener is running then check the queue manager error logs for any connection errors from the MQ explorer.
Are you sure the qmgr and its listener are running and that you have a SYSTEM.ADMIN.SVRCONN channel? That is the server-connection channel used for remote administration of a queue manager. This technote may be helpful.
Is this on a modern Windows or Linux server? If so, did you open the port (i.e. 1414) in the firewall?
Sometimes when we create a Queue manager remote administration objects are not created that's why we get such errors because it is unable to find these objects. To create them right click on the queue Manager, Select Remote Administration objects and create them and start the listener.
I experienced this same error and the queue was configured correctly.
I was using Eclipse and switched to the MQ Explorer setup available from IBM web page.
After that, I was totally able to see the queues and everything I was supposed to see.
I am trying to put a message into Websphere MQ queue from an Orchestration which is deployed on Cast Iron Live. I have used secure connector since the orchestation is deployed on Cast Iron. When I am trying to execute the flow, it fails and the message is not placed in MQ queue. The below are the errors:
Error while trying to call remote operation execute on Secure Connector for activity
com.approuter.module.mq.activity.MqPut and Secure Connector LocalSecureConnector,
error is Unable to put message on queue null. MQ returned error code 2538.
Unable to put message on queue null. MQ returned error code 2538.
Fault Name : Mq.Put.OperationActivityId : 163
Message: Unable to put message on queue null. MQ returned error code 2538.
Activity Name:Put MessageFault Time: 2015-07-15T05:40:29.711Z
Can someone please help me resolve this. Please let me know if any further details are required.
Here are the details:
Cast Iron flow is deployed on Cast Iron Cloud i.e Cast Iron Live
MQ is running on-premise
The port I am trying to connect is 1414.
Have a secure connector running on the machine where MQ is installed.
MQ version is 8.
In Cast Iron flow, I am using an MQ connector, by giving the hostname where MQ is running, port: 1414, Channel Name : SYSTEM.DEF.SVRCONN and username as mqm. Tired using my log on username, by adding it to mqm group. But this also dosent seem to work.
The return code is instructive:
2538 0x000009ea MQRC_HOST_NOT_AVAILABLE
This indicates that Cast Iron is attempting to contact MQ using a client connection and not finding a listener at the host/port that it is using.
There are a couple of possibilities here but not enough info to say which it might be. I'll explain and provide some diagnostics you can try.
The 2538 indicates an attempt to contact the QMgr has failed. This might be that, for example, the QMgr isn't listening on the configured port (1414) or that the MQ listener is not running.
The error code says the queue name is "null". The question doesn't specify which queue name the connector is configured with but presumably it's been configured with some queue name. This error code suggests the Secure Connector on the MQ server side doesn't have its configuration installed.
The Cast Iron docs advise connecting with an ID in the mqm group but do not mention that on any MQ version 7.1 or higher this is guaranteed to fail unless special provisions are made to allow the admin connection. It may be that it's actually failing for an authorization error and the connector not reporting the correct error.
If it is as simple as the listener not running, that's easy enough to fix. Just start it and make sure it's on 1414 as expected.
Next, ensure that the Secure Connector has the configuration that was created using the Cast Iron admin panel. You need to understand why the error code says the queue name is null.
Now enable Authorization Events and Channel Events in the QMgr and try to connect again. The connector on the MQ server should connect when started and if successful you can see this by looking at the MQ channel status. However, if unsuccessful, you can tell by looking at the event messages or the MQ error logs. Both of these will show authorization failures and connection attempts, if the connection has made it that far.
The reason I'm expecting 2035 Authorization Error failures is that any QMgr from v7.1 and up will by default allow an administrative connection on any channel. This is configured in the default set of CHLAUTH rules. The intent is that the MQ admin would have to explicitly provision admin access by adding one or more new CHLAUTH rules.
For reasons of security SYSTEM.DEF.* and SYSTEM.AUTO.* channels should never be used for legitimate connections. The Best Practice is to define a new SVRCONN, for example one named CAST.IRON.SVRCONN and then define a CHLAUTH rule to allow the administrative connection.
For example:
DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
ADDRESS('127.0.0.1') +
USERSRC(MAP) MCAUSER('mqm') +
ACTION(REPLACE)
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
USERLIST('*NOBODY') +
WARN(NO) ACTION(REPLACE)
The first statement defines the new channel.
The next one allows the connections from 127.0.0.1 which is where the Secure Connector lives. (Presumably you installed the internal Secure Connection on the same server as MQ, yes?) Ideally the connector would use TLS on the channel and instead of IP filtering the CHLAUTH rule would filter based on the certificate Distinguished Name. This rule is not nearly so slective and allows anyone on the local host to be an MQ administrator by using this channel.
The last statement overrides the default CHLAUTH rule which blocks *MQADMIN with a new rule that blocks *NOBODY but just for that channel.
After using MQ Explorer 7.5 on Ubuntu 12 to add JMS Connection factories and a JMS Destination it decided to stop displaying my two queues and subsidiary info as well as the new JMS information. I tried a few things to get it to work again: stopping the queue manager/restarting, rebooting etc. even reinstalling MQ Explorer without any luck.
I can do a status on the "empty" queues folder and it then shows me my two queues; each has "queue monitoring" set as off. Is this relevant? Can I set it on ?
Am I stuck with MQ Explorer to display and manage the JMS objects (there doesn't seem to be any documentation about how to use the command line for JMS objects) ?
more detail:
so I created objects using the following:
DEFINE QLOCAL (QUEUE_FROM)
DEFINE QLOCAL (QUEUE_TO)
SET AUTHREC PROFILE(QUEUE_FROM) OBJTYPE(QUEUE) PRINCIPAL('bsmith') AUTHADD(PUT,GET)
SET AUTHREC PROFILE(QUEUE_TO) OBJTYPE(QUEUE) PRINCIPAL('bsmith') AUTHADD(PUT,GET)
SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('bsmith') AUTHADD(CONNECT)
DEFINE CHANNEL (CHANNEL1) CHLTYPE (SVRCONN) TRPTYPE (TCP)
SET CHLAUTH(CHANNEL1) TYPE(ADDRESSMAP) ADDRESS('127.0.0.1') MCAUSER('bsmith')
DEFINE LISTENER (LISTENER1) TRPTYPE (TCP) CONTROL (QMGR) PORT (1415)
START LISTENER (LISTENER1)
So these were all visible then in MQ Explorer using a user that was part of group mqm.
I then added, using MQ Explorer, a file based JMS context, two JMS Connection Factories, and a JMS Destination. After adding the JMS Destination the MQ Explorer stopped displaying everything except the Queue Manager and the JMS context in the MQ Explorer UI.
if I try to start the LISTENER again using the command START LISTENER (LISTENER1) it will tell me that it is already started. When I add a new queue to the queue manager using a command it also is not visible on the UI. A refresh doesn't change this.
/etc/environment is set to:
export JAVA_HOME=/usr/lib/jvm/jdk1.6.0_45
export MQSERVER="SWI_CHANNEL/TCP/COM22189(1415)"
export MQ_JAVA_LIB_PATH=/opt/mqm/java/lib64
export MQ_JAVA_INSTALL_PATH=/opt/mqm/java
export MQ_JAVA_DATA_PATH=/var/mqm
export LD_LIBRARY_PATH=/opt/mqm/java/lib64
CLASSPATH=.:/opt/mqm/java/lib/com.ibm.mq.jar:/opt/mqm/java/lib/com.ibm.mqjms.jar:/opt/mqm/samp/wmqjava/samples:/opt/mqm/samp/jms/samples:${JAVA_HOME}:${MQ_JAVA_LIB_PATH}:${CLASSPATH}
PATH=".:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:${JAVA_HOME}/bin:${JAVA_HOME}:/usr/lib/jvm/jdk1.6.0_45/jre/bin:${MQ_JAVA_LIB_PATH}"
trying the JMS Admin tool suggested gives :
/opt/mqm/java/bin$ ./JMSAdmin -v
Licensed Materials - Property of IBM 5724-H72, 5655-R36, 5724-L26,
5655-L82 (c) Copyright IBM Corp. 2008, 2011 All Rights Reserved. US
Government Users Restricted Rights - Use, duplication or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp. Starting
WebSphere MQ classes for Java(tm) Message Service Administration
Initializing JNDI Context... INITIAL_CONTEXT_FACTORY:
com.sun.jndi.fscontext.RefFSContextFactory PROVIDER_URL:
file:/C:/JNDI-Directory JNDI initialization failed, please check your
JNDI settings and service. The name '"/C:/JNDI-Directory"' cannot be
resolved
Error: javax.naming.NameNotFoundException; remaining name
'"/C:/JNDI-Directory"
The error Error: javax.naming.NameNotFoundException; remaining name '"/C:/JNDI-Directory" can be resolved by creating a folder named JNDI-DIRECTORY in C drive. This is the place where .bindings file will get generated.
I installed MQ Client(7.0.1) in my computer,and write an app using c# to connect to remote Websphere MQ server.I have reference amqmdnet.dll in my project.below is my connect code:
MQEnvironment.Host = ip address;
MQEnvironment.Channel = channel name;
MQEnvironment.Port = 1414;
MQQueueManager qmgr = new MQQueueManager("qm name");
But when new MQQueueManager(),throw a type initializer for 'IBM.WMO.MQ.QueueManager'.
I am very confused about the exception.
Can you help me?
Can you give the complete stack trace of the exception? Type initializer exception occurs when an creation of an class instance fails. This exception is basically a wrapper for an internal exception. So knowing the details of the internal exception is helpful. You can put the MQQueueManager qmgr = new MQQueueManager("qm name"); in a try/catch block and print the complete exception.
From what I know this exception generally occurs if WMQ Client libraries are not installed. The amqmdnet assembly refers to other WMQ libraries, for example amqxcs2.dll and if they are not installed, this exception can be thrown.
You can use the dspmqver -a command output to check what has been installed.