You are currently browsing Dale Lane's articles.
We’re moving to join the developerWorks hosted blog on messaging - so please update your bookmarks and feed-readers to point to:
http://www.ibm.com/developerworks/blogs/page/messaging/
The new blog covers more than just WebSphere MQ, so if you also work with products such as WebSphere Message Broker, you should find even more to interest you. If it’s just WMQ you want, there is a WMQ-only feed.
We will leave these posts up for as long as possible, as a resource for people who find this site via Google, but we won’t be adding any new posts here.
Thanks to everyone who has read and commented on our posts here, and we hope you enjoy the developerWorks blog.
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.
A few weeks ago, Saket posted a link to a very readable document on Data Conversion under WebSphere MQ.
The post has seemed very popular, so I thought I might be helpful to follow it up with some thoughts on diagnosing problems when using data conversion.
The document Saket pointed at is pretty much the definitive reference document, but in this post I will try and add some general observations, and describe a simple technique for diagnosing data conversion problems if things go wrong.
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.
The changes to Daylight Savings Time (DST) in the United States this year raised questions about the way time is handled by various software programs.
The implications of the DST change for WebSphere MQ are fairly straightforward. In summary, there are no issues with the WMQ runtime (on either the servers or clients) as WebSphere MQ uses UTC and is essentially oblivious to DST. There are some issues surrounding the Java runtime environments supplied with WebSphere MQ. This is all well documented in a TechNote on IBM.com.
Despite this, the DST changes this year were a good reminder of the implications of making changes to the system clock on servers. In this post I will discuss some implications with WebSphere MQ.
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.
In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources (memory, threads, file descriptors), then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them.
The inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrsta processess, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrsta processes even when the queue manager is shut down.
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.
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.
I’d like to invite you all to suggest ideas for future blog posts. If there is anything that you would find interesting or useful for us to cover, now would be a good time to let us know.
This could be a HOWTO for something that you think is a little complicated (or even just where something is easy to get wrong).
It could be some background where you think it would be interesting to hear about how a bit of WebSphere MQ works, or why it works the way that it does.
Is there any part of WebSphere MQ where you think we could go into more detail than there currently is in the manuals?
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.
The latest version (v3.0.2) of the IBM Support Assistant (ISA) has been released. If you’ve not tried ISA before, this is a good opportunity to give it a try.
IBM Support Assistant (ISA) is a free local software serviceability workbench that helps you resolve questions and problems with IBM software products. It provides quick access to support-related information along with serviceability tools for problem determination.
A nice thing about this approach is that it provides a single consistent approach to Support across a large number of IBM software products. (See the ISA site for a current list of ISA plugins.)
The search facility it provides is particularly nice - you can search across product manuals, forums, newsgroups, Technotes, articles, white papers, and more. The screenshot shows an example of searching for SSL information, filtering for just TechNotes and manual pages. It produces a simple-to-navigate page, with the first 32 results (this can be changed in Preferences) downloaded to the ISA, making clicking on links to change pages nearly instantaneous.
If the ISA doesn’t help you find the information you need to solve a problem yourself, it can also be used to collect diagnostic information that can be useful to IBM Service in diagnosing the problem further.
If you have a number of IBM products installed, the ability to do all of this from one interface - consistent across the different IBM products - can be very useful.
For those who haven’t seen it highlighted somewhere else already, I thought it was worth pointing out that 6.0.2.1 is now available for distributed platforms.
Typically, Fix Packs are scheduled regression-tested cumulative packages of fixes. (A more detailed overview of what Fix Packs and Refresh Packs can be found in the WMQ Maintenance Strategy).
A full list of the fixes included in this Fix Pack can be found in the 6.0.2.1 Fix List.
Unusually, some new function has also been included in this update. Details are contained in the 6.0.2.1 README, but to summarise:
- Support for J2EE Connector Architecture (JCA)
A JCA resource adapter for WebSphere MQ, allowing JMS applications and message driven beans running in an application server, to access the
resources of a WebSphere MQ queue manager. - Windows 64-bit support
Support for Windows XP Professional x64 Edition, Windows Server 2003 Standard x64 Edition and Windows Server 2003 Enterprise x64 Edition. Note that from this point on, WebSphere MQ installs will include abin64directory on all Windows operating systems. - .NET applications on 64-bit Windows
32-bit versions of the .NET framework versions 1.1 and 2.0 are both supported for use with Windows 64-bit operating systems. - DES SSL Cipherspec Suppression in SSLFIPS mode
An updated version of GSKit which rejects DES-based SSL Cipherspecs when the queue manager or client is in SSLFIPS mode.
It’s worth noting that this is currently the last version 6 maintenance pack announced for this year to include new function. For the most up-to-date copy of the maintenance pack schedule, see the WebSphere MQ Planned Maintenance Release Dates page.
.
Update: I should be clear that I am talking about maintenance for distributed platforms in this post. For full details, please click through to the links included above.
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.
Solaris Zones are Sun’s approach to virtualization which was introduced in Solaris 10. You can have several ‘zones’ running on a single server, and they all look like separate machines. I got to play with them towards the end of last year, but it’s been a quiet week this week so I thought I’d raise it and see if it would spark any discussion.
There are loads of ways that you can configure Solaris Zones, but essentially the idea is that you can have multiple lightweight Zones by having them all share the core system files. With only one copy of the bulk of the core OS, you can have fairly small zones - each of them accessing the core files across a read-only mount.
In this post, I discuss some of the problems that you may face when using WebSphere MQ with Solaris Zones and the background behind them. I also outline a number of practical approaches to deal with these problems.
An interesting discussion on the use of client connection wildcards came up on mqseries.net today. This is documented in the Application Programming Reference and Clients manuals, but I’ve not seen it used very often and it can help to see how it works with a practical example.
In this post, I’ll go through an example of why you might want to use a wildcard in an MQCONN call and show the effect that it has.
I had to migrate a Windows machine running WebSphere MQ v5.3 to WMQ v6 this evening. The WebSphere MQ Explorer on the machine was configured with client connections to a large number of remote queue managers that I needed to continue to be able to administer.
I didn’t realise that we don’t migrate queue manager connections when you go from WMQ v5.3 to the new Eclipse-based v6 WMQ Explorer. (Although I guess I can see why - they are very different apps). And I didn’t fancy the thought of having to manually enter each remote queue manager into Explorer one at a time after migration.
So I had a quick look at the ways that the different Explorers store their queue manager connection information, to see if it would be possible to convert between the two.
I needed to write a small C WebSphere MQ app today which made MQGET calls in a number of places. In all of these, it was likely that the initial message buffer would be too small for the message, and would need to be able to handle MQRC_TRUNCATED_MSG_FAILED.
So, I wrote a quick common function wrapping MQGET, that would free the message buffer in these cases and allocate a bigger one (using the size indicated by the DataLength field returned - see the Application Programming Guide for more detail if you’ve not done this before).
It looked something like this:
void MQGETwithGrowingBuffer(MQHCONN Hconn, MQHOBJ Hobj,
PMQVOID pMsgDesc, PMQVOID pGetMsgOpts,
PMQLONG BufferLength, PMQVOID* ppBuffer,
PMQLONG pDataLength,
PMQLONG pCompCode, PMQLONG pReason)
{
MQGET(Hconn, Hobj, pMsgDesc, pGetMsgOpts,
*BufferLength, *ppBuffer, pDataLength,
pCompCode, pReason);
if(*pReason == MQRC_TRUNCATED_MSG_FAILED)
{
free(*ppBuffer);
*BufferLength = *pDataLength;
*ppBuffer = (char*) malloc(*pDataLength);
MQGET(Hconn, Hobj, pMsgDesc, pGetMsgOpts,
*BufferLength, *ppBuffer, pDataLength,
pCompCode, pReason);
}
}If you’re writing a C++ application, you can let WMQ handle this for you - automatic buffer management is an option in the WMQ C++ API. (When you do a ‘get’ call in C++ with automatic buffer management, the WMQ C++ libraries do something fairly similar to what I’ve done above - see Using C++ for a description).
But when wouldn’t this work?
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.
SSL certificates are stored in SSL key repositories. The SSLKEYR attribute of the queue manager identifies which key repository to use - giving the path of the key repository file. But the key repository can hold several certificates, so we identify which certificate to use for which queue manager or client using the certificates’ label names.
For queue managers, the certificate label name should be ibmwebspheremq with the queue manager name (converted to lower-case) appended.
For clients, the certificate label name should be ibmwebspheremq with the name of the user who runs the client (converted to lower-case) appended.
There we go - easy. Except that’s not all there is to it. There is an exception. This post is a discussion of that exception, how it came to happen, and a discussion on whether it’s a good idea or not.
Update (13/12/2007): The contents of this post have since been largely superseded by the release of PowerShell cmdlets for WebSphere MQ.
PowerShell is Microsoft’s new command line. Released last year, it introduced a number of enhancements over the traditional Windows Command Prompt, including a novel object-oriented approach.
I won’t go into the background about PowerShell - if you’re interested, a quick search will turn up masses of information, everything from detailed guides to the first impressions of obscure bloggers!
One of the more interesting features is the ability to access the .NET API - directly from the command line. So I thought it would be interesting to point out that with PowerShell, the .NET bindings available for WebSphere MQ means that you can interact with queue managers from the command line.
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.
A new SupportPac developed by Hursley’s Peter Broadhurst (an author of the Redbook WebSphere MQ V6 Fundamentals) has been released today.
SupportPac MS6A “provides a mechanism to simplify installation of, or migration to, WMQ V6.0 and automatically roll out WMQ maintenance to an infrastructure of WMQ installations”.
This gives you a single automated way to migrate multiple systems to WebSphere MQ version 6, as well as a simple way to keep all of your version 6 systems up to date with the latest Fix Packs and Refresh Packs.
In my last post outlining the different GSkit commands for SSL administration, I forgot to mention a couple of tools that I regularly use: SSL Config Wizard and SSLcheck.
They are both SupportPacs provided free from ibm.com.
WebSphere MQ supports the use of SSL to provide secure transmission of data, and administration of this is provided with the supplied tool GSkit.
Implementing this can be complicated, and with new users this tends to be due to difficulties with knowing what they want to achieve; or difficulties knowing which of the many similar-sounding GSKit verbs (e.g. import, add or receive) is appropriate for their uses.
In this post, I outline a few simple approaches to SSL administration and give GSKit script examples showing how they could be implemented.
Triggering can be used to start applications in response to messages arriving on queues. But what do you do when nothing happens? How do you tell the difference between the queue manager not launching your application, and your application being launched but not doing anything?
Once WebSphere MQ launches the executable, it doesn’t take any further action to determine what happens to it - for example, no return codes from the executable are collected (as the trigger monitor can’t wait for what could be a long-running application). Without any such information, it can sometimes be difficult to confirm whether a triggered application is not being triggered, or is being started but ends, perhaps prematurely, with an error.
One of the nice things about starting out with WebSphere MQ is that 90-day free trials are available to try it out. But what happens if, after trying it out (and paying for it!), you decide you like it and want to keep the environment you’ve spent the last ninety days setting up? Many new users don’t realize that it is possible to upgrade your trial setup to the full product, without needing to reinstall WMQ or recreate their queue managers.
