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.
Last part of a series of posts on working with IBM WebSphere MQ from Windows PowerShell
Over my last four posts, I’ve given an introduction to how to use Windows PowerShell to administer WebSphere MQ, using SupportPac MO74.
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 : New-WMQ, Get-WMQ and Set-WMQ. Where things get interesting is in combining them through the use of the object pipeline.
Part 4 of a series of posts on working with IBM WebSphere MQ from Windows PowerShell
This week, I’ve been demonstrating how to use Windows PowerShell to administer WebSphere MQ systems, using the support provided by SupportPac MO74.
On Tuesday, I discussed creating new WMQ objects from PowerShell. Today, I want to talk about how to modify existing WebSphere MQ objects.
Part 3 of a series of posts on working with IBM WebSphere MQ from Windows PowerShell
In my last couple of posts, I’ve been demonstrating the support for using Windows PowerShell to administer WebSphere MQ systems, using SupportPac MO74.
On Monday, I discussed getting WMQ objects with PowerShell. Today, I want to talk in more detail about getting specific objects into PowerShell.
Part 2 of a series of posts on working with IBM WebSphere MQ from Windows PowerShell
Yesterday, I wrote about the support for using Windows PowerShell to administer WebSphere MQ systems, using the support introduced by SupportPac MO74, and demonstrated how to get your WMQ objects.
Today, I’m going to talk about how to create new WMQ objects.
Part 1 of a series of posts on working with IBM WebSphere MQ from Windows 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.
You can change the minimum display time down to zero. This makes the Explorer seem much more responsive.
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.
SupportPac MSL1 is available here
Once installed, see the man pages ibm.com-WebSphereMQ( 
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[1]; 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.
You need a (default) queue manager on your local workstation so that runmqsc can use it to collect MQSC commands and send them on to the command queues of your 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.
This restriction makes sense. As per several RFCs (RFC952, RFC1035, RFC1178) and the Wikipedia entry on hostnames, underscores_are_not_valid characters in hostnames.
… 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.
One of the topics which was requested a couple of times last week was about the information in FFST files.
In this post, I will try to give an introduction to these files, and identify some actions which can be taken in the event of an FFST file being generated.
What is FFST?
FFST stands for First Failure Support Technology, and is technology within WebSphere MQ designed to create detailed reports for IBM Service with information about the current state of a part of a queue manager together with historical data.
Update (13/12/2007): The contents of this post have since been largely superseded by the release of PowerShell cmdlets for WebSphere MQ.
A better way to do filtering
A follow-on post from WebSphere MQ scripting using PowerShell - part 2
In hindsight, my approach to filtering was too restrictive (filtering by name only). Instead, it would be better for the function to just return queue objects, and let the user use the built-in functions to filter on them as they want.
Display objects…
- Choose which attributes you want to be outputted
- Apply filters - return queues whose parameter(s) match certain filters (supporting complex queries with AND and OR)
- Sort by a parameter
And do this for local or remote queue managers.
I’m leaving Display-WMQQueues as it is, and have started a new function - Get-WMQQueues - to do this.
This is much much better:
PS-WMQ DALE > Get-WMQQueues | Select Name, CurrentDepth
Name CurrentDepth
---- ------------
SYSTEM.ADMIN.ACCOUNTING.QUEUE 0
SYSTEM.ADMIN.ACTIVITY.QUEUE 0
SYSTEM.ADMIN.CHANNEL.EVENT 0
SYSTEM.ADMIN.COMMAND.QUEUE 0
SYSTEM.ADMIN.LOGGER.EVENT 0
SYSTEM.ADMIN.PERFM.EVENT 0
SYSTEM.ADMIN.QMGR.EVENT 1
SYSTEM.ADMIN.STATISTICS.QUEUE 0
SYSTEM.ADMIN.TRACE.ROUTE.QUEUE 0
SYSTEM.AUTH.DATA.QUEUE 54
SYSTEM.CHANNEL.INITQ 0
SYSTEM.CHANNEL.SYNCQ 0
SYSTEM.CICS.INITIATION.QUEUE 0
SYSTEM.CLUSTER.COMMAND.QUEUE 0
SYSTEM.CLUSTER.REPOSITORY.QUEUE 1
SYSTEM.CLUSTER.TRANSMIT.QUEUE 0
SYSTEM.DEAD.LETTER.QUEUE 0
SYSTEM.DEFAULT.INITIATION.QUEUE 0
SYSTEM.DEFAULT.LOCAL.QUEUE 0
SYSTEM.PENDING.DATA.QUEUE 0
TINY_QUEUE 12
.
PS-WMQ DALE > Get-WMQQueues | Select Name, CurrentDepth | Where { $_.CurrentDepth -gt 0 }
Name CurrentDepth
---- ------------
SYSTEM.ADMIN.QMGR.EVENT 1
SYSTEM.AUTH.DATA.QUEUE 54
SYSTEM.CLUSTER.REPOSITORY.QUEUE 1
TINY_QUEUE 12
Update (13/12/2007): The contents of this post have since been largely superseded by the release of PowerShell cmdlets for WebSphere MQ.
This month’s issue of TechNet Magazine includes an article giving a nice introduction to PowerShell - the new Windows command shell and scripting language. It was a useful reminder that I had said that I was going to look into writing some useful PowerShell functions for WebSphere MQ, so last night I had a quick play to see what I could do with it.
In this post, I discuss how PowerShell can be used to extend the capabilities of existing command-line tools for WMQ, and outline how I got it working.
I began by thinking of what PowerShell could do to supplement runmqsc. To recap from my earlier post, PowerShell is a scripting language which supports the use of .NET libraries, such as that provided with WMQ. Two obvious points suggested themselves as places to start:
- Connect to remote queue managers over a client connection
- rather than just local queue managers
- Provide more powerful wildcards and filtering when using DISPLAY to show queue manager objects
- rather than just accepting full names, or prefix followed by *
The full source for my script is included at the end of this post. The rest of this post breaks the script down and discusses each part.
endmqm lets you stop a running queue manager. But there are rare occasions where it wont work and you need to kill the queue manager processes yourself. As a queue manager is made up of a number of processes, there is a list which gives the recommended order to stop the processes in.
Considering how rare a situation this is, it never ceases to surprise me how many WMQ Sys Admins have some sort of kill script in their arsenal, ready to nuke an errant queue manager.
But as people do, and as often these scripts have been around for a long while, I thought it was worth highlighting that the order in which you stop the processes was changed for WMQ v6, point out where the new order can be found, and briefly talk about some interesting points behind the order.
A fictional encounter containing useful information about WebSphere MQ and affinities
—— Scene 1/1 —————
<Herd of buffalo exit stage right. A few seconds later, Ian enters stage left and Dylbert enters stage top>
| Dylbert: | Hi Ian. Got a minute? I have a quick MQ clustering question for you. |
| Ian: | Hey Dylbert. Sure I have a minute, fire away. |
| Dylbert: | Thanks. How should I stop my queue manager, QM1? It’s in a cluster and I want to bring it down for maintenance. |
Refresh Pack 6.0.2.0 added some new plugins to the Eclipse-based WebSphere MQ Explorer. One of these is the “Tests plug-in”. The idea of the Tests plugin is to use the Eclipse ‘Problems View’ to display feedback about your WMQ configuration.
The “Tests plug-in” can itself be extended with user-written tests. This allows you to customize the WMQ Explorer so that it displays messages in response to any situation that you are interested in.
In this post, I’ll give a bit of background to the Tests plug-in, and walkthrough the steps involved in adding a new Test to the WMQ Explorer.
The WebSphere MQ Explorer GUI provides a user-friendly way to administer your queue managers.
With a little work, you can use it as a read-only ‘viewer’ instead. If you have some staff who don’t have authority to make changes to the WMQ network, but need them to be able to monitor what is happening, this would let them use WMQ Explorer to do it. If your staff without authority to make changes are the ones with less WebSphere MQ experience, then this might be a useful approach.
In this post I’ll walk through the steps required to set this up for a single queue manager, and highlight a couple of potential problems to watch out for.
The most obvious place to check which TCP ports your WebSphere MQ channel listeners are configured to use is:
DISPLAY LISTENER(*) PORT in runmqsc.
But that’s not the only place to check. It’s easy to miss one of the places, so in this post, I’ll quickly outline the different factors that affect the TCP port that a channel listener will use.
