Configuring mq websphere 7 with .net

Question

I am trying to connect to a remote queue using c#. I tried many ways to connect to the remote queue but it always fails with common errors like: MQRC_CHANNEL_CONFIG_ERROR or MQRC_HOST_NOT_AVAILABLE.

What I am doing is this:

        string channel = "QM_TEST.SVRCONN"; 
        string hostname = "<serverIp>"; 
        string queueName = "QM_TEST"; 
        string port = 1414; 

        props.Add(MQC.HOST_NAME_PROPERTY, hostname); 
        props.Add(MQC.CHANNEL_PROPERTY, channel); 
        props.Add(MQC.PORT_PROPERTY, port ); 
        props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED); 

        MQQueueManager mqQueue = new MQQueueManager(queueName, props); 

I have tried changing this but all failed.

I think that my problem is the server configurations.. can you point me to a full guide to how to configure a server and connect to it with .net?

My problem is connecting to a REMOTE server using .net and not to a local server.

Thank you!

Answer 1

The problem was that the CCSID between the client and the server were different.

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaf.doc%2Fcs12480_.htm

On the client side I had to put

Environment.SetEnvironmentVariable("MQCCSID", "437");

Thats why I got:

MQRC_CHANNEL_CONFIG_ERROR 

Answer 2

I'm guessing the problem (or at least a problem) is here:

MQQueue mqQueue = new MQQueueManager(queueName, props);

This should be

queueManager = new MQQueueManager(queueManagerName, properties);

If you have installed the WebSphere MQ client to the default location, there are many sample programs under the following directory:

C:\Program Files (x86)\IBM\WebSphere MQ\tools\dotnet\samples\cs\base\

There are a number of sample programs there for various tasks. If you have the latest V7.1 client installed then you will see the following programs:

SimpleAsyncPut
SimpleClientAutoReconnectGet
SimpleClientAutoReconnectPut
SimpleGet
SimpleMessageProperties
SimplePublish
SimplePut
SimpleReadAhead
SimpleSharingConversation
SimpleSubscribe
SimpleXAGet
SimpleXAPut

There are also WCF and XMS samples.

If you need the client code, please see my response to another SO question here for links.

Update:

Here's the normal diagnostic process.

1. If the WMQ components were installed by relocating libraries or classes from somewhere else, perform an install using the full vendor-supplied client media. This includes troubleshooting utilities such as trace, dspmqver, etc. It also resolves any library or class mismatch issues.
2. Use the pre-compiled client programs to test the connection. The amqsputc, amqsgetc and amqsbcgc programs require the MQSERVER environment variable as described here. The Q program from SupportPac MA01 is a separate download but has the advantage of NOT requiring any environment variables, CCDT files or other dependencies.
3. If the sample programs fail, check the QMgr's error logs at [WMQ install]/qmgrs/[QMgr name]/errors/AMQERR01.LOG for messages. Also check for FDC files and errors in [WMQ install]/errors.
4. If no errors on the QMgr side, attempt the connection again while using a client-side trace as described here and here.

Most client problems are resolved through installation of the full WMQ client as supplied by IBM. (Conversely that implies most people are installing by grabbing DLL or JAR files.) If the problem persists, error log inspection on the QMgr and client side usually reveals the underlying cause. If these do not work then tracing usually diagnoses the remaining issues.

UPDATE 2:
Per the error messages posted at MQSeries.net, the channel has a security exit set. A security exit is external code that the channel calls out to when starting a channel. There is no way to know what the exit expects or does without having access to the code or docs of the exit. If the exit is written in-house, you'll need to talk to the programmer to figure out what it requires. If the exit is a commercial product then you will need to get the documentation for it.

Alternatively, alter the channel so that SCYEXIT is blank to disable the exit.

The data posted at MQSeries.net was as follows:

MQ9575: DCE Security: failed to get the user's login name.

EXPLANATION:

System call 192.168.50.55 to get the login name of the user running WebSphere
MQ client application process 5 failed with error value -1. This occurred in
security exit function create_cred. The exit will now attempt to open channel
using the DCE default login context.
ACTION:
If you wish to run using the DCE default login context take no action. If you
wish to run using the user's login name as the DCE security exit principal
examine the documentation for the operating system on which you are running MQ
clients and reconfigure the operating system as necessary to allow the
192.168.50.55 call to succeed. 

Note that it states the call is failing in the security exit.