WAS MQ .net Consumer need WAS MQ Client? - ibm-mq

I have a WAS MQ server and some queues which have couple of messages. I have a java consumer to get those messages and everything is OK. When I want to get those messages by .net or delphi application; it's not working and throw an error code 2058. When I install WAS MQ Client in my PC; the error went away.
I want to install my .net app in more than 25 clients and I do not want to install WAS MQ Client to all of those clients. Is there a .dll or configuration or something like that to avoid install WAS MQ Client?
I am using these two dll: amqmdnet.dll, amqmdxcs.dll

Unfortunately It's not possible for now.
See below link for more details:
.net using IBM MQ without full MQ client install

Here is a good document to solve this problem.
I think in .NET we have to using Managed Connections instead of MQ Client.

Related

Windows Server MQ client interact with Unix MQ server

I am doing lot of analysis for a new Java MQ client requirement got some doubts. Currently in the Unix system Queues Queue manager all created where MQ server is running.
In order to run Java MQ client we are going to install MQ client on other Unix Solaris system. Mean while we had one windows server where MQ client installed before going to MQ client installation on unix System need to clear my clarifications.
Since I am new MQ.
Can we run Java MQ client from windows server to connect MQ server unix system(Queues,Queuue Manager)
If yes what need for this to connect Windows Server to unix Solaris
The code is compiled with MQ libraries
Is any error will come to face.
It would be great if you provide steps or solution.
Yes, you can run the Java MQ client from any machine to connect to a queue manager on any other machine. The MQ Clients (Java, 'C' or .NET version) all support any platform to any platform combinations, and all support any MQ version to any MQ version. So for example, you can have a V8 Client on Windows connecting to a V9 Queue manager on Unix. Equally you can have a V9 Client on Windows connection to a V8 Queue manager on Unix, i.e. any to any version can be upwards or downwards.
In order to connect a client to a queue manager, you will need the client libraries on the client machine, in your case the Java client.
You will also need to ensure that your queue manager has a TCP/IP listener running and that you know the port number.
You will need a channel definition on the queue manager of a type called SVRCONN, and know the name of it. e.g.
DEFINE CHANNEL(MQGEM.SVRCONN) CHLTYPE(SVRCONN) DESCR('Channel for my client application to connect to')
In order for your Java client to connect to the queue manager it will need to use
The channel name
The host name of the machine where the queue manager is running
The port number of the TCP/IP listener
If you face any errors, they may be related to connectivity, because your application is connected by the network to the queue manager. Remember to pay attention to any return codes you get from MQ, they will be in the form of 4 digits, e.g. 2059. For Java you should ensure you get hold of the linked exception. It may also be useful to look in the error log of the queue manager too.
You may also face security errors if this is your first use of IBM MQ. The queue manager is locked down by default so that remote applications cannot simply connect in and do damage (e.g. delete important messages from other applications!). There are a number of posts on here that describe these errors and their solutions. Best advise, get the MQRC code (4-digits) and the AMQERR01.LOG error message from the queue manager. Armed with this information you should be able to describe and diagnose any error situations you encounter.

Check if WebSphere MQ is in Native Mode or JMS Mode

I'm trying to figure out how to check what mode one of my IBM WebSphere MQ installations is running in.
In particular, I need to find out if this particular installation is running in Native Mode or JMS Mode.
I thought maybe I could find an answer using one of the provided IBM MQ CLI commands found HERE, but none of them seem to tell you what mode the installation is running in, or even how to change the mode.
Does anyone have any advice or guidance on how to detect what mode my installation is running in?
The client may use the JMS client OR the native client to connect to WMQ.
The server always runs in the same mode - and can handle both native and JMS.
To figure out which type of client you have connecting into a queue manager, i.e. a native 'C' client or a JMS client, you can use the following command while the client application is running:-
DISPLAY CHSTATUS(*) RPRODUCT
The different types of clients have different values in RPRODUCT. The native 'C' client will show MQCC and JMS will show MQJM.
Reference
DISPLAY CHSTATUS - Look for attribute RPRODUCT for full set of values
IBM MQ Little Gem post on RPRODUCT and RVERSION

connect to ibm mq broker using activemq client

I used IBM MQs on my local machine to connect to a remote IBM MQ Queue Manager on a client machine for sending and receiving messages.
Due to some issues I need to uninstall IBM MQs on my end.
Can I connect to the client remote queue manager using Apache ActiveMQ? (With SSL)
If possible please guide me how to proceed with it.
If not please suggest any alternative solutions to connect.
No. Connect to it using the WebSphere MQ Client. It is freely downloadable as SupportPac MQC75 and includes support for several languages, including C and Java. Rather than just grabbing the jar files, please install the entire client distribution. IBM includes a number of diagnostic utilities, tracing and so forth in that distribution. These make debugging much easier and IBM requires them to be installed if you open a support ticket. Since the client is free, requiring the diagnostic tools to be installed seems reasonable.
The documentation for the client is here.
Active MQ uses a different wire protocol and its client won't work with WebSphere MQ.

AMQ9504: A protocol error was detected for channel

I'm unable to connect remotely from WebSphere Application Server with Queue Manager at WebSphere MQ. Anyhow it get connected to Queue Manager from WAS that is installed on same machine. I'm using version 7.5 of WebSphere MQ and version 7.0 of WebSphere Application Server.
While attempting to connect WAS remotely to Queue Manager following error messages were logged.
Error Message from WebSphere MQ:
1/30/2013 21:12:09 - Process(3624.6) User(MUSR_MQADMIN)
Program(amqrmppa.exe)
Host(KHILT-269) Installation(Installation1)
VRMF(7.5.0.0) QMgr(QM.TEST)
AMQ9504: A protocol error was detected for channel 'TEST_CHANNEL'. EXPLANATION: During communications with the
remote queue manager, the channel program detected a protocol error.
The failure type was 11 with associated data of 0. ACTION: Contact the
systems administrator who should examine the error logs to determine
the cause of the failure.
Error Message at WebSphere Application Server:
A connection could not be made to WebSphere MQ for the following
reason: CC=2;RC=2009
As it can be seen from logs, I have created Queue Manager as QM.TEST and channel as TEST_CHANNEL. The listener port defined for the Queue Manager is 1417 along with protocol TCP.
I did lot of google but didn't find any appropriate solution. I appreciate any help in this regard.
Thanks in adv, KAmeer
I had a similar issue where I have WAS 7 and WMQ 7.5. I was able to make a connection to my existing WMQ 7.0 QM but not my new WMQ 7.5 QM. Apparently there was a change to the WMQ components bundled with WAS 7 after the initial release 7.0.0.0. After updating the resource adapter I was able to make a successfull connection to both queue managers.
The queue manager generates protocol error and terminates the connection immediately when it receives unexpected TSH flow from the client. As a result the client receives 2009 error. Technically, low level MQ client will be able communicate with higher version MQ queue manager and vice versa unless there are known restrictions and/or there is a MQ defect/APAR. The error message indicates the queue manager is running at MQ 7500 and this is MQ base 7.5 version. It is recommended upgrading the queue manager to the latest fixpack available to rule out any known problems. You could also try disabling shared conversion on the SVRCONN(i.e. setting SHARECNV to 0) channel and check whether it workarounds the problem until the problem is resolved.
Open a PMR with IBM as this sounds like a bug.
the cause for this is mq 7 client cannot talk to mq 7.5, the client needs to use mq 7.5 jar files
I had this problem. In my case was the mq library that was doing an MQGET with an infinite loop, so the lib was locked on the mqget while i called the kill and generated an event and tried to disconnect while the get was still running. As the mqget does not support unlocking via signal, i had to change the code to not stay infinite on get and add some flags on the kill command so the app could detect that it was time to die, when it returned from the get.

How can I test a program which publishes to Websphere MQ

I have a program which publishes data to IBM Websphere MQ via the MQAX200 interface. I'm struggling to work out how to test it.
What's the simplest way of setting up an application to consume the messages from the queue and confirm they're correct? I don't currently have any MQ infrastructure here (that's on the client's site).
Do I need a message broker? Are there any open source implementations? Or do i need to purchase Websphere MQ, in which case what's the minimal license I'd require?
Thanks
Ben
As your application is written using a MQ interface, you need MQ to test. If it's just for testing, you can use the trial version of MQ.
As far as I know MQAX200 interface supports only P2P messaging and not Publish/Subscribe messaging. So using your application put message to a queue and then use the application like amqsgetto receive message.
You don't need message broker.
First, you need to clarify what it is you are trying to do. If you are publishing messages then your test program will need to subscribe. If you are putting messages into a queue then your test program will need to GET messages from the same queue.
The WMQ Trial Download will get you a 90-day WMQ license for no charge. The trial code includes the server and the client libraries so you can set up a QMgr and then test your program in client or bindings mode, as appropriate. If you elect to install the sample code you also get compiled binaries with which you can test. For example, amqsget gets messages and amqssub subscribes to topics, both using bindings mode (shared memory). The client versions of these (amqsgetc and amqssubc) attach over the network. If you are using topics, make sure to subscribe before you publish. If using queues, make sure to GET after you PUT.
Other useful programs include amqsgbr to browse messages on queues and amqsbcg which will hex-dump the messages and parse the message headers. Also, WMQ Explorer comes with the Windows and Linux versions of the trial and you can use that to browse, subscribe or get messages.
Just write a simple Java JMS program that subscribes to the Topic. THen you only need to install the free WebSphere MQ Client.
This article is a bit old but should do.

Resources