When I go to my WebSphere MQ explorer, and connect to a remote queue manager and go to --> Advanced --> Listeners, I do not see any listeners defined. But I am able to create a remote JMS client, connect to this queue manager by using a channel connection and publish a message to a topic.
So what is the purpose of listeners? In my case, things are working fine without listeners.
WebSphere MQ listeners are what accepts remote connections and start inbound channels. Modern queue managers will almost always have listeners defined but it is also possible to specify a default port for the QMgr to listen on without actually defining a listener. This is unusual, though. For older versions of MQ it was common to use inetd to start channels. This method doesn't use a listener.
So rest assured that something on your QMgr is listening for connections. Since you are not seeing it there are three likely possibilities:
The listener name starts with SYSTEM. and your Explorer view is set to filter SYSTEM objects.
The default port has been specified in the qm.ini file
You have a really old QMgr using inetd
By the way, go get a new version of WMQ Explorer. Since you have an Advanced --> Listeners you must have an old version. Download from SupportPac MS0T.
Related
I have inherited an IMB MQ (V6) system that has multiple brokers. Is there a way to explore everything succinctly ?
i.e. I know what queue managers are running, so without "runmqsc"ing each and every manager, how can i find broker names, listeners, etc ?
There is the Explorer running but again points to knowing the manager and port to have it connect successfully.
For MQ, the dmpmqcfg command can be useful to output your configuration info to a file.
For the broker, try the mqsilist command to list installed brokers and their associated resources.
this webpage may be of help to you:
Performing health checks for WebSphere Message Broker
http://www.ibm.com/developerworks/websphere/library/techarticles/0801_cui/0801_cui.html
To work out which queue managers are running on your machine, use thedspmq command. Then you'll know each queue manager and can runmqsc to each one, or point MQ Explorer to each one, or whatever you need to do next.
I am configuring WAS to connect to MQ via CCDT, and should be using a Queue Manager Name with wild cards, i.e *QMan.
It is accepted in the Queue Connection Factory Screen and in the Activation Spec Screen, but it is not accepted in the Queue Configuration Screen. As shown on the below image, I am forced to leave the Queue Manager field blank. And my application is not received MQ messages. I am suspecting this might be the reason.
Any ideas why I cannot configure the Queue Manager in Queue screen? And what is the common problem if message listener is not receiving, even if the MQPUT is working.
I had double checked my CCDT configuration in Activation Spec, and have check the jndi names, everything is configured correctly.
Also note that it is working if I connected directly to the MQ via host/port etc. But I have to use CCDT to utilize our MQ cluster.
The Queue Manager (or Queue Sharing Group) name on the JMS Queue panel defines where the queue is located and not how you connect to it. It is the Queue Manager name in the JMS connection factory or activation specification that defines which queue manager your application connections to.
So it is correct that you can't enter a * in this box.
If the connection is not working when using a CCDT then it is likely to be another problem that this Queue Manager name box. Note: you can't use an XA connection with CCDTs due to the fact that a CCDT won't guarantee you will connect back to the same queue manager in the event of XA recovery.
I'm trying to configure a clustered websphere application server that connects to a clustered MQ.
However, the the information I have is details for two instances of MQ with different host names, server channels and queue manager which belongs to the same MQ cluster name.
On the websphere console, I can see input fields for hostname, queue manager and server channel, I cannot find anything that I can specify multiple MQ details.
If I pick one of the MQ detail, will MQ clustering still work? If not, how will I enable MQ clustering given the details I have?
WebSphere MQ clustering affects the behavior of how queue managers talk amongst themselves. It does not change how an application connects or talks to a queue manager so the question as asked seems to be assuming some sort of clustering behavior that is not present in WMQ.
To set up the app server with two addresses, please see Configuring multi-instance queue manager connections with WebSphere MQ messaging provider custom properties in the WAS v7 Knowledge Center for instructions on how to configure a connection factory with a multi-instance CONNAME value.
If you specify a valid QMgr name in the Connection Factory and the QMgr to which the app connects doesn't have that specific name then the connection is rejected. Normally a multi-instance CONNAME is used to connect to a multi-instance QMgr. This is a single highly available queue manager that can be at one of two different IP addresses so using a real QMgr name works in that case. But if the QMgrs to which your app is connecting are two distinct and different-named queue managers, which is what you described, you should specify an asterisk (a * character) as the queue manager name in your connection factory as described here. This way the app will not check the name of the QMgr when it gets a connection.
If I pick one of the MQ detail, will MQ clustering still work? If not,
how will I enable MQ clustering given the details I have?
Depends on what you mean by "clustering". If you believe that the app will see one logical queue which is hosted by two queue managers, then no. That's not how WMQ clustering works. Each queue manager hosting a clustered queue gets a subset of messages sent to that queue. Any apps getting from that queue will therefore only ever see the local subset.
But if by "clustering" you intend to connect alternately to one or the other of the two queue managers and transmit messages to a queue that is in the same cluster but not hosted on either of the two QMgrs to which you connect, then yes it will work fine. If your Connection Factory knows of only one of the two QMgrs you will only connect to that QMgr, and sending messages to the cluster will still work. But set it up as described in the links I've provided and your app will be able to connect to either of the two QMgrs and you can easily test that by stopping the channel on the one it connects to and watching it connect to the other one.
Good luck!
UPDATE:
To be clear the detail provide are similar to hostname01, qmgr01,
queueA, serverchannel01. And the other is hostname02, qmgr02, queueA,
serverchannel02.
WMQ Clients will connect to two different QMgrs using a multi-instance CONNAME only when...
The channel name used on both QMgrs is the exactly the same
The application uses an asterisk (a * character) or a space for the QMgr name when the connection request is made (i.e. in the Connection Factory).
It is possible to have WMQ connect to one of several different queue managers where the channel name differs on each by using a Client Connection Definition Table, also known as a CCDT. The CCDT is a compiled artifact that you create using MQSC commands to define CLNTCONN channels. It contains entries for each of the QMgrs the client is eligible to connect to. Each can have a different QMgr name, host, port and channel. However, when defining the CCDT the administrator defines all the entries such that the QMgr name is replaced with the application High Level Qualifier. For example, the Payroll app wants to connect to any 1 of 3 different QMgrs. The WMQ Admin defines a CCDT with three entries but uses PAY01, PAY02, and PAY03 for the QMgr names. Note this does not need to match the actual QMgr names. The application then specifies the QMgr name as PAY* which selects all three QMgrs in the CCDT.
Please see Using a client channel definition table with WebSphere MQ classes for JMS for more details on the CCDT.
Is MQ cluster not similar to application server clusters?
No, not at all.
Wherein two-child nodes are connected to a cluster. And an F5 URL will
be used to distribute the load to each node. Does not WMQ come with a
cluster url / f5 that we just send message to and the partitioning of
messages are transparent?
No. The WMQ cluster provides a namespace within which applications and QMgrs can resolve non-local objects such as queues and topics. The only thing that ever connects to a WebSphere MQ cluster is a queue manager. Applications and human users always connect to specific queue managers. There may be a set of interchangeable queue managers such as with the CCDT, but each is independent.
With WAS the messaging engine may run on several nodes, but it provides a single logical queue from which applications can get messages. With WMQ each node hosting that queue gets a subset of the messages and any application consuming those messages sees only that subset.
HTTP is stateless and so an F5 URL works great. When it does maintain a session, that session exists mainly to optimize away connection overhead and tends to be short lived. WMQ client channels are stateful and coordinate both single-phase and two-phase units of work. If an application fails over to another QMgr during a UOW, it has no way to reconcile that UOW.
Because of the nature of WMQ connections, F5 is never used between QMgrs. It is only used between client and QMgr for connection balancing and not message traffic balancing. Furthermore, the absence or presence of an MQ cluster is entirely transparent to the application which, in either case, simply connects to a QMgr to get and./or put messages. Use of a Multi-Instance CONNAME or a CCDT file makes that connection more robust by providing multiple equivalent QMgrs to which the client can connect but that has nothing whatever to do with WMQ clustering.
Does that help?
Please see:
Clustering
How Clusters Work
Queue manager groups in the CCDT
Connecting WebSphere MQ MQI client applications to queue managers
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 am new to Websphere, and at this client site, we are running an older version of Websphere in an older version of RAD. I used a python script to define a queue factory and some queues, using a script provided by another individual at the site. However, there was not mention of a queue manager in the script. It appears that the queues are created, I can see that they are defined in the Admin Console. Same is true for the queue factory. The admin console does not seem to expose the name of a queue manager, however.
I have been googling for a few days trying several different angles, but always come back to no answer. There seems to be tool called MQ Explorer, but that comes with Websphere MQ, which is not installed. No one here seems to have tried anything like this before, of if they have, may not have attempted what it is I am trying to achieve.
Ideally, what I would like to do would be to connect to the queue with a third party tool called MQ Visual Edit, for example.
There are about 3 or 4 questions here. Let's see if I can address all of them.
First, creating administered objects is completely separate from defining queues in the queue manager. Typically, the WebSphere MQ admin defines the queues and topics, then provides the host, port, channel, QMgr and queue/topic names to the WAS admin who then generates the matching connection factory and queue or topic objects. Defining the WAS objects does not create the corresponding WMQ objects, nor does it even imply that they exist. From your description, it sounds as though they may not have been defined on the QMgr.
In fact, it is not even obvious from your description that you are using MQ as your transport. If WAS is configured to use it's own JMS implementation (System Integration Bus or SIBus for short) then the connection factories and other objects may point to SIBus instead of WMQ. If you created a QCF for WMQ then someone should have already provided the details you are requesting - QMgr name, host, port and channel name.
WMQ Explorer is available as a free, stand-alone download called SupportPac MS0T. In order to use it, or any of the other 3rd party desktop tools such as MQ Visual Edit or SupportPac MO72 you will need to know the QMgr name as well as host, port and channel name. In addition, if the WMQ admin has enabled any security, you will need to be authorized to connect and, at a minimum, inquire on WMQ objects. The WMQ admin will provide these details to you. Assuming you have the QMgr details and are sufficiently authorized, just download and install SupportPac MS0T and point it at WMQ. Instructions on all things WMQ (including WMQ Explorer) are at the Infocenter pages. Since the stand-alone WMQ Explorer is V7 you will want the V7 Infocenter for any Explorer help. If the QMgr is at V6 then you may need to refer to the V6 Infocenter as well.
That answers the questions in the body of your post. The answer to the question in the title - how do I find out the QMgr name - is "ask the WMQ administrator." You should be given the name when you get the host, port and channel. That said, you often do not need it. A WMQ client will connect to any QMgr if provided the host, port and channel. This is what allows your client app to fail over to a different QMgr. Things like WMQ Explorer are the exception because they should not fail over. If you have a primary and backup QMgr, you typically want WMQ Explorer to see them both at the same time (so for example that you can configure them identically) and if one QMgr is down you want Explorer to report it as such. Therefore Explorer requires a QMgr name but most apps do not.