You are currently browsing the category archive for the ‘administration’ category.
I wanted to announce the release of the most requested feature for the PowerShell library for WebSphere MQ SupportPac : support for administering remote queue managers.
I’ve already covered my work on PowerShell for WebSphere MQ at some length on this blog, so I won’t duplicate that here. (If you are interested in a recap, this is a good place to start).
With this latest release, you can now manage queue managers across multiple servers from a single PowerShell window on your local workstation.
You can now write commands which query and/or modify your queues, channels, etc. across multiple queue managers spanning multiple servers on multiple operating systems. All in a single command or line of script.
It currently works with queue managers running on supported Windows and UNIX-based operating systems. (It is not currently possible to administer z/OS queue managers with this, however work on this has begun and should be added in a future release).
Ideas for what can be done with this are welcomed – I’ve put a couple of examples after the break.
For my final post in this series, I want to look at some more advanced uses of PowerShell, focusing on things that cannot be done easily with runmqsc or WebSphere MQ Explorer.
The last four posts have covered the cmdlet basics :
Set-WMQ. Where things get interesting is in combining them through the use of the object pipeline.
On Tuesday, I discussed creating new WMQ objects from PowerShell. Today, I want to talk about how to modify existing WebSphere MQ objects.
On Monday, I discussed getting WMQ objects with PowerShell. Today, I want to talk in more detail about getting specific objects into PowerShell.
Windows PowerShell is an object-oriented command line shell and scripting language, available for Windows XP, Windows Vista, and Windows Server 2003.
With the release of SupportPac MO74 (WebSphere MQ – Windows Powershell Library), Windows PowerShell can now be used to administer WebSphere MQ. In the next few posts, I’ll go through a few common WMQ system administration tasks in PowerShell.
For people new to Window PowerShell, I’ve added a few links to good resources for beginners at the end of my post.
Instructions on installing the PowerShell support for WebSphere MQ can be found in the MO74 documentation (pdf). I’ll be writing about what you can do once you’ve done that.
To start with – getting your WMQ objects.
It seems that not everyone knows this and it’s well worth knowing.
The default preferences for WMQ Explorer are to show progress dialogs for a minimum of 3 seconds. For example, when deleting a queue there is a progress dialog displayed saying “Deleting the object named MY_QUEUE”. You will always be waiting for 3 seconds before getting the “The object ‘MY_QUEUE’ was deleted successfully” message, even though the command itself was actioned in less than a second.
Given that you just asked for the queue to be deleted you might not want to artificially wait for 3 seconds.
Choose Windows -> Preferences and click on the “WebSphere MQ Explorer” folder to bring up the panel below.
Change the value from 3 to 0.
We’re pleased to announce the availability of SupportPac MSL1: WebSphere MQ for Linux – Automatic Startup. It provides an init script which will start IBM WebSphere MQ queue managers when the system is started, and stop them cleanly when the system is shut down.
A configuration file allows system administrators to specify which local queue managers are to be controlled. The default behaviour is to control all local queue managers.
The supplied init script assumes the existence of an LSB-compliant init system – RedHat users may need to install a RedHat-supplied RPM named lsb.rpm or redhat-lsb.rpm to meet this requirement.
Once installed, see the man pages ibm.com-WebSphereMQ(8) and ibm.com-WebSphereMQ(5) for details of its configuration.
I’ve posted before about setting up WebSphere MQ Explorer as a read-only viewer using setmqaut and MCAUSER ids – a post which has proved quite useful to some readers.
A similar topic which seems to raise questions is using WebSphere MQ Explorer to administer remote queue managers where all server-connection channels are secured using SSL/TLS.
In this post, I will give some background about the issues surrounding using WMQ Explorer with SSL, and outline how it can be used with multiple queue managers.
Emir Gaza (Consulting IT Specialist, Hursley Software Lab Services) and I are currently putting together a list of SSL gotchas based on our personal experiences and, of course, those of our customers. Our list covers many problems and solutions already well documented in the manuals (e.g. Error messages), but what we’re trying to do is compile a single list containing both common problems and those with sometimes cryptic solutions.
We aim to expand this list in future with more items and more detail, but for now, here’s the list we have compiled… Comments most welcome…
Assuming your phone has a browser, it is now possible to utilise the HTTP support in supportpac MO71 to view your WebSphere MQ queues, messages and more. The following blog entry gives an overview of MO71 HTTP support and simple instructions on accessing it from a web browser.
In the previous post, we took a brief look at some of the things we can learn from the queue manager using the DISPLAY command in runmqsc. It turns out that there is a lot of information available. So, what if we want to filter the results to see something more specific?
I first learned MQ quite a few years ago, back in the days of MQSeries version 5.1. The instructor on my MQ course told us that the most useful thing we could learn for administering MQ would be the command interface – the runmqsc program. Why? Simple: it is consistent between platforms; it is scriptable; and it is extremely powerful, exposing everything you might want to know about how your queue manager is running.
In version 6 of WebSphere MQ, the command program has been considerably enhanced. If you’ve been used to the range of commands available in WebSphere MQ 5.3 or earlier, it is worth looking again the functions that are available. If you are new to the product, it is also worth knowing how to get the most from runmqsc.
This post is not going to be a full tutorial on using runmqsc. I just wanted to highlight some of the things that are possible in WMQ v6. In fact, I’m just going to focus on what we can learn using the DISPLAY command – some “did you know?”-style tips. For full reference information, check out the Infocenter.
runmqsc is the command-line tool typically used to adminster local queue managers. It seems that some WebSphere MQ users don’t realise that they can also use
runmqsc -w to administer remote queue managers.
This lets you do all of your runmqsc administration work from a single point.
The diagram shows an example – note that your local queue manager will need channels going to and from the remote queue managers that you want to administer, to allow the commands to be sent and the replies returned.
Full details on how to do this can be found in Remote administration from a local queue manager in the WebSphere MQ System Administration Guide. It includes further diagrams explaining how the MQSC commands are passed on, and all of the commands that you will need to configure it correctly.
It may be useful to be aware that there are some restrictions when adding new queue managers to MQ Explorer. I recently had a case where a customer could not enter the hostname into the dialog. It turned out that the hostname had an underscore (_) character in it. The entry field in MQ Explorer prevents the user from entering this character.
… hostname labels can only be made up of the ASCII letters ‘a’ through ‘z’ (case-insensitive), the digits ‘0’ through ‘9’, and the hyphen. Labels can not start nor end with a hyphen. Special characters other than the hyphen (and the dot between labels) are not allowed, although they are sometimes used anyway. Underscore characters are commonly used by Windows systems but according to RFC 952 they are not allowed…
A solution could be to reference the IP address of the queue manager in question, or possibly to alias the hostname in the hosts file so that it does not contain underscores. Note that I have not tested the latter solution, but it should work.