I was wondering if you can help me solve the following problem.
After a while of no-messages being received by the Queue Manager, the Queue Manager goes to 'sleep' and unless you use IBM WebSphere Explorer to 'start the queue' using the command.
On the other hand, if you send a message and expect a response, it will say - Cannot connect.
Then, if you send the same message again, expecting the response, I've noticed the Queue Manager wakes-up.
So to summarize, my question is:
Does anyone know of a command to 'wake-up' the Queue Manager, before sending an actual message(as above).
Thanks in Advance,
IBM MQ Queue manager does not go to sleep. If queue manager is running, then it's awake and is no "wake up". There must be some reason because of which queue manager might have shutdown. Check logs in "errors" folder.
Can you please explain what you mean by 'start the queue'? because there is nothing like that. There is start queue manager.
What MQ reason code are you getting when it says "cannot connect".
Ok,
So I spoke to the admin of the MQ Service and there is a parameter they can set (some timeout I think) that sets it to 0 so it never 'sleeps'.
This will fix the problem.
Related
I would like to add some conditional logic to our Java application code for attempting to create a JMS Topic Connection. I have seen problems in the past stemming from attempting to create a connection when the MQ server had been restarted or was currently down. One improvement I added was to check for the quiescent state, and another was to increase the timer before attempting reconnection to our durable topic queue.
Is there a way to confirm with the MQ server/topic/channel that it is up and running and a connection request can safely be made?
The best way to confirm that a queue manager (and the channel you are using to connect to the queue manager) is up and running is to attempt to connect to it.
If your connection attempt fails, you will get an MQ Reason code telling you exactly why. This is a much better way to confirm than any administrative command, because it also confirms that your application, and it's security context is correct and able to connect to the queue manager. It is completely possible to have an up-and-running queue manager but an application that is not yet correctly configured to use it. So connect from the application and if it works, the queue manager is up-and-running.
Your comment about having an increased timer before attempting to reconnect after a failure is well made. It doesn't help anyone if you hammer the queue manager with lots of repeated and close together connection attempts until it is ready to accept your connection, but still anything that is going to test the availability of the queue manager needs to ultimately connect to it, so very simply, just connect.
I have being trying to transfer a message between two host. I followed Jump start WebSphere MQ development on Linux article, It's work fine with two queue manager in single machine.
Here I created one local queue, one transmission queue and one remote queue and also create the sender , receiver and SVRCONN channel in both queue manager. I can transfer the message between two queue manager.
But I try this with two host, when I try to start the channel it doesn't work.
Much appreciated if anyone could help me with this issue Or let me know if more clarification on my question is required.
You will find a starter here:
http://www.redbooks.ibm.com/redpapers/pdfs/redp0021.pdf
The part which is relevant to your case starts at page 46 of the MQ Series Red Book.
At the very least you should enroll to a CBT course and get MQ training.
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').
How do I ping an IBM WebSphere MQ queue manager? Is there a way through cmd.exe? Is there a way to use WebSphere to do it?
I have tried
runmqsc QMGR "qManager"
Thanks!
Depends on what exactly you mean by 'ping'. Do you want to check for running WMQ processes? For local connectivity to the QMgr? Remote connectivity? Whether a specific channel or queue is available?
Locally you can use dspmq and it will show you all the locally defined QMgrs and their status. Remotely, you can ping the listener but if you do not complete the connection, it causes WMQ to log an error and cut a trace. Remotely, it is better to use the WMQ client to make a connection. If the connection succeeds then the QMgr is up. If you get an error, then the error code (or linked exception in JMS) will tell you how far into the WMQ stack the connection request got - i.e. whether the listener was down, or if it was up and there was a problem at the QMgr, or if you don't have authority, etc.
There are sample programs that come with MQ such as amqsget and amsqput, and their client-based equivalents amqsgetc or amqsputc, which connect and get or put a message. These can be used in scripts to check MQ status. Also, there is a tutorial here that provides a stand-alone JMS program that can connect which you could customize as a ping application.
The format for the command you tried is:
echo dis qmgr qmname | runmqsc QMGRNAME
This echoes a command to display the QMgr's attributes into runmqsc and executes it. The manual containing all the runmqsc commands for v7.0 is here. The v7.1 manual is here.
Finally, although I don't think this is what you are looking for, WMQ has a ping command. It is used on one queue manager to test the channel connectivity to another queue manager. The WMQ ping exercises the channel path and validates things such as the remote listener is up, the remote queue manager has a compatible channel instance defined, etc. However, this is more useful to an MQ administrator than to a developer wanting to know if the queue manager is up. For that you'd want some version of one of the suggestions above.
I am a novice with Websphere MQ and require some novice help.
I am using Websphere MQ Explorer to connect to a queue but do not know how to write the connection string. I have all the details (host, port, channel, queue manager name) but do not know how to put them together correctly as a connection string.
Can any help this novice?
Thanks
Here is one way to get you started (assuming your queue manager under default configuration):
Queue Managers->Context Menu->Add Remote Queue Manager
Fill in Queue manager name:
Select Connect directly
Next
Fill in:
Host name or IP Address:
Port number:
Server-connection channel:
Next
Next
If you have a user configured usually mqm user, you will need to tick the "Enable user identification" here and fill in the user/pass here.
Next, Next, Finish.
As you see, you might need to fill in other information such as SSL if you configured it at the target queue manager.
Then you should be able to see the queue manager in the tree. Click on the Queues icon to find the queue you care about.
Hopefully you are using the latest WebSphere MQ Explorer which is now a stand-alone download. You can find it at SupportPac MS0T which is available from the main SupportPac page. There are significant advantages to using that version, including Explorer Plug-Ins for WMQ FTE, WebSphere Message Broker, the MS0P plug-in which parses event messages, and more.
The screen shot below shows the connection dialog in the latest WMQ Explorer. It has separate fields for hostname (or IP address). port and channel. Just plug in the appropriate values and you are good to go!