Simple question on Q Program SupportPac. Do we install this on the MQ Server or MQ Client?
Take your pick. Q can connect using bindings or client mode so put it wherever you need it. If you have a client app that you are trying to debug, Q can use the same channel and CONNAME. (If the channel uses SSL and your app is Java, you might need to convert the keystore to a kdb format first.) And of course, Q on the same server as the queue manager can access MQ in bindings mode, provided you have sufficient authority to do so.
Related
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.
What is the use of a server conn in Websphere MQ and why do we go for it.
What is the difference between client conn and server conn.
In some respects these are two opposite things, but they need to match to make a client connection to a queue manager. Its quite a generic topic but fortunately there is lots of useful documentation about this in google / IBM knowledgebase e.g. https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q016480_.htm
As a queue manager, if you are going to let clients connect into you, you need to be able to provide some configuration details (heartbeat intervals, max message sizes, user exits) - these are configured on a SVRCONN channel
As an application, if you want to connect into a queue manager via the client bindings (usually to go to another machine), you need some information about the configuration to use and these are configured on a CLNTCONN channel.
The application 'provides' a CLNTCONN channel, and once the connection is made, an equivalent SVRCONN channel is looked up, and the configuration values are negotiated and the connection made.
An application can 'provide' a CLNTCONN channel at least 3 common ways...
- As part of an MQSERVER environment variable
- Via a client channel table (MQCHLLIB/MQCHLTAB environment variables)
- During an MQCONNX call it can provide the channel details
More details here:
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q027440_.htm
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
I'm a beginner on WebSphere MQ, I was working on MQ 6 and it was working fine, but now I've installed MQ 7.1 and when I try to create a new Queue Manager I can do it But it can't connect and it gives me the following error :
Do you have any idea about that? Thank you :)
You can look up any WebSphere MQ error code if either the WebSphere MQ Client or Server are installed using the mqrc command. In this case:
C:\Users\MUSR_MQADMIN>mqrc 2059
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
The 2059 usually indicates that the listener is not running or the queue manager is down. There's a different error code if the listener is running and the QMgr name is wrong and another one if the connection is made to the right QMgr but the channel name is wrong. Sometimes you can get a 2059 if the channel was closed at the server side by an exit but since you didn't mention any exits, I'm assuming in this case that its listener problem.
Hopefully by now you are defining a listener object rather than using inetd or the runmqlsr command. Defining an object and setting it to start and stop under QMgr control is the most reliable way to configure it.
Once you get past the 2059, you should be aware that as of WMQ V7.1, the queue managers are secure by default and won't accept any remote client connections unless you explicitly authorize them. This is the opposite of the behavior of V6 where on a newly defined queue manager running a listener, anyone with a TCP route to it could administer it and remotely execute OS code as the mqm user. So I expect that the next problem you run into will be 2035 errors.
I've been told this means more work for the WMQ administrator. The only case in which that's true is if the V6 or earlier queue manager had been configured without security. If the tasks to secure a V7.0 QMgr are compared to the tasks to provision access on a v7.1 and higher QMgr are compared, provisioning access turnds out to be easier. However if you liked the V7.0 behavior, you can always alter the QMgr to disable CHLAUTH rules. Needless to say, leaving security enabled is highly encouraged.
To debug security errors, alter the QMgr to enable authorization events using the runmqsc command ALTER QMGR AUTHOREV(ENABLED). Next, download and install SupportPac MS0P into WebSphere MQ Explorer. Then when you do get a security error, use WebSphere MQ Explorer to look at the queue. Right-click on the queue and select the option to parse the event messages. This will tell you in excruciating detail all the information you need to debug the authorization error.
Finally, if you wish to read up on the new security features, go to t-rob.net/links and look at the conference presentations there. There are also some articles indexed if you scroll down.
In the screen-shot, I see hostname "127.0.0.1" and port # 1414. If it is a local queue manager then connect directly to it.
Also, each queue manager MUST use a unique port number. If you had it working with WMQ v6 queue manager, is this the same queue manager? If not, then make sure each queue manager uses a different port number (i.e. 1415, 1416, etc...)
I got same problem. but i resolved this by :
1. created a listener manually (define lstr(lstr1) port(xxxx) control(qmgr)
2. setmqaut mcauser('mqm').
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.