Three ways of managing WebSphere MQ 6
I am using three ways or maybe I should say three tools in Linux to manage, monitor and configure MQ on the fly. I thought why not share my way of doing those tree things. So here they are, lets start with the most basic and standard one.
Commandline
The “runmqsc QMNAME” command is the most basic command for monitoring and configuring MQ. It can also show you real time data about what is happening in MQ.
Eclipse with plugin
These days IBM is shipping there MQ with eclipse who has an plugin for controlling MQ “ies30″. I am not an big fan of this approach. Eclipse is just to big for this kind of things, and another bummer is they only have this for 32 bit platform and not for 64 bit.
Never the less the tool performs oke and does everything you need to control MQ.
MQJExplorer
This is my favorite tool and I use it a lot. It is not being developed anymore and it is quite old but I like it very much. The reason I like it very much is because it’s small and it works in windows, linux and in 32 bit, 64 bit because it’s java.
You can do almost anything you need as in “ies30″ and it works fine and it’s lightweight. Although not developed anymore you can still download it here.
Maybe you where expecting more info about the tools than I wrote on this blog, but I think it’s not necessary to do so. The reason why so is because you should just try them all and make your own opinion about what is best for you. I have days that I am using commandline and days I use one of the other two. It also depends where and how you are working. When I am doing some things remote I like to do it commandline and with MQJExplorer, but when I am working local I use “ies30″ when I am on an 32 bit machine.
Thanks for sharing! I hope your fondness for MQJExplorer does not stop you from moving to v7.0. If you test it with that version, topics will not work but I wonder whether it will handle other objects, for example those with new attributes. If you do test it with v7.0, please post your results.
One thing to remember about using runmqsc is to always be mqm when you administer the QMgr. Any time an object is created, WMQ will give unlimited authorization to the primary group of the user creating the object. As an administrator if your primary group is mqm then no problem. But if your primary group is “staff” and mqm is secondary, then “staff” gets authorized to do all MQI and all admin commands on that object. That includes the dangerous auths such as delete, setall, etc.
What I have seen in the past is where an administrator’s account is created with mqm as the primary group but over time the group enrollments change and some other group becomes primary. From that point on any objects created are grossly overauthorized ans this happens silently. Because they are over- and not under-authorized, there is never an application failure to point out the problem. At one bank where I did an assessment, literally thousands of objects over the years had silently been authorized to “staff” because of this.
My recommendation to address this is just not put administrators in the mqm group. Instead, set up rights to allow the administrator to become mqm when needed. If the administration is via desktop tools like WMQ Explorer or the MO71 SupportPac, you can use SSL to restrict the connection so only administrators can use it and then put mqm in the MCAUSER of the channel.
– T.Rob
Testing MQ 7 is in my planning but i just haven’t found any time to actually do it. I will give my opinion about it when I test it. Have been working with 5.3 and 6 for some time now, and must say I like MQ 6.
I understand the issue your are addressing here and I can not say anything else than to agree on you.