You are currently browsing the category archive for the 'webspheremq' category.
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.
How many full repositories should you have in a WebSphere MQ cluster? The Queue Manager Clusters manual says “preferably two” and “Having only two full repositories is sufficient for all but very exceptional circumstances” (see doc).
The reason for having two rather one is for availability reasons (one is a single point of failure). Single point of failure is probably somewhat of an overstatement, as the impact of all full repositories being unavailable is that definitional changes (e.g. define/alter cluster queues or cluster queue receiver channels) cannot be shared with the cluster.
Application messages between available cluster queue managers can still flow when full repositories are not available, so the impact is to cluster object changes rather directly on application traffic.
Here’s a little utility which allows you to match an integer against WMQ constants, or find WMQ bit flags it contains.
You might find it useful if you are looking at output from an application which prints WMQ fields as an integer, or in hex.
Read the rest of this entry »
Ever puzzled by CCSIDs, Encoding or Data conversion issues? Here is an excellent document on this topic.
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.
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.
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.
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.
We’ve just brought out a new SupportPac that allows access to WebSphere MQ using HTTP: MA0Y: IBM WebSphere MQ Bridge For HTTP.
There is no client involved here - just connect using whatever method you like Ajax, C++, Java, anything that can make a socket connection and send HTTP! This makes it the first zero-footprint client to WMQ.
We’ve defined a bunch of HTTP headers that encapsulate the message headers and the body of the message is sent as the HTTP body.
The support enables three of the standard HTTP verbs:
- GET - browse (get with browse) the currently highest message on the queue.
- DELETE - delete (destructive get) the currently highest message on the queue or topic.
- POST - post (put) a message to the queue or topic.
The SupportPacs system continues to expand - the most recent addition is the new WebSphere Business Process Management SupportPacs page.
Most of the SupportPacs on this page are related to WebSphere Business Modeler and WebSphere Business Monitor. However, there’s also a useful plugin for WebSphere Integration Developer that provides a wizard to help developers to use the MQ-CICS bridge. It also provides assistance with handling the MQCIH header required by the bridge. Worth a look if you need to call a CICS program across the bridge from a mediation or business process.
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.
Here are some simple sample applications for WebSphere MQ JMS that you may find useful. You may use them to verify your installation or to learn more about WebSphere MQ JMS semantics.
Both applications use client bindings rather than local bindings; and do not make use of JNDI for simplicity. They can be run as standalone J2SE/JSE programs.
Note: Applications need minor tweak in the config section and destination names according to your setup.
Author: Saket Rungta, wastedmonkeys.com
Here is a minimalist cookbook for getting SSL working with XMS .NET client when communicating with WebSphere MQ*. Comments and suggestions are very welcome!
* Understanding of basic JMS and XMS concepts is assumed in this cookbook. For further information about JMS, see ‘Using Java’ book and for further information about XMS see ‘Message Service Clients for C/C++ and .NET’ book shipped with XMS.
Meta Notes
- Currently, MQ SSL only applies to the unmanaged client*. This functionality is not available for the fully managed client (which is the default). This functionality is not applicable for the bindings mode, as there is no network communication in bindings.
- The following only applies to MQ v6, as v5.3 has a different SSL story, at-least for Windows, I think.
So, in source code we must do the following:
myConnectionFactory.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT_UNMANAGED);
* XMS .NET for WebSphere MQ delegates the security to lower layer of ‘MQ classes for .NET’. ‘MQ classes for .NET’ supports three connection modes - unmanaged client, fully managed client and bindings. XMS .NET transparently allows a selection between these three connection modes thru the XMSC.WMQ_CONNECTION_MODE property on a ConnectionFactory. For further information about these modes, see ‘Using .NET’ book. However, in a nutshell: unmanaged client is .NET wrapper with underlying C library, fully managed client is 100% pure .NET and bindings is (by definition) unmanaged, since it does IPC with the queue manager processes. (client modes communicate over network, bindings mode does IPC).
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.
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.
I came across The Support Authority series of WAS related articles on developerWorks the other day, with their latest article on WAS trace released yesterday.
In this series a group of IBM’s technical support professionals are taking the time to explain the trace, and other RAS (reliability, availability and serviceability) features, of WebSphere Application Server and IBM’s JVM.
If you use WMQ as a messaging provider for WAS, or standalone WMQ JMS applications, I suggest taking a look.
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.
A February post on listeners lead on to some discussion on the operation of channels, and diagnosing issues.
I thought this comment from John merited a post of its own.
There are a number of status indicators and other sources of information available on the operation of WMQ channels - with new ones for WMQ V6.0.
So here’s a summary of some things that you can use in diagnosing channel issues and links to more information. There’s lots out there on this subject, so do add links to other useful docs and sources of information.
Read the rest of this entry »
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. |
SSL channels for WebSphere MQ provide an excellent way to protect messages as they move from one queue manager to another. However, how can you protect messages when they are at rest on a queue? Also, how can you tell if the message has been altered since it reached the queue and how do you know who really sent the message?
WebSphere MQ Extended Security Edition can be used to solve these problems and more. It employs a certificate based security infrastructure which provides authentication, authorisation and auditing for a WMQ network. This means messages can be digitally signed and/or encrypted for their entire lifetime inside WMQ. WMQ ESE also provides authentication of users and their authorisation to queues and messages. WMQ ESE is administered centrally for easy to manage end to end security.
For more information on WMQ ESE, checkout the product page here.
If there is a good amount of interest in this topic then I’ll follow up with some more articles on how to implement and make best use of WMQ ESE
Most discussions on using SSL with WMQ Java applications (using the WMQ Classes for Java) talk about using the javax.net.ssl.keyStore etc. Java System Properties to specify a certificate store and password.
This works well for most applications.
However, there are a few limitations to this approach:
- The SSL context is initialised only once - the first time it is used.
If the path/password is incorrect, the JVM must be terminated before trying again. - Debugging is only available through using javax.net.debug system property.
This produces a large amount of output on the console. - Only one certificate store can be used per JVM.
You might want to use different certificates to connect to different queue managers.
So, this post has the starting point for an alternative.
There are often queries about using the WMQ Explorer from a desktop (without a WMQ install), to admin back-end queue managers.
If you have a back-end Windows installation of WMQ, RDC is a good option.
But what about when you’ve got a back-end Linux installation of WMQ?
Well, here’s an option:
Run the WMQ Explorer on the server, but using the X server of your desktop…
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.
A small selection to key resources:
- An excellent RedBook for Introduction to MQ and messaging concepts, plus in depth techie stuff (pdf)
- WebSphere MQ library, when interested to study a topic in-depth: v6 books (pdf collection)
- WebSphere MQ InfoCenter, when you want to search for a key word or concept, across all MQ books
- dW WebSphere MQ zone
- ibm.com product page
- Specialised Google Search Engine for MQ sites
- WebSphere MQ SupportPacs
- WebSphere MQ Recommended Fixes
Note: Please help to improve the quality of wikipedia page for MQ!
Using IronPython and XMS .NET under-the-covers. Works like a charm for Point-to-point messaging and Publish/Subscribe messaging using WebSphere MQ.
And, you can change five lines and connect to WebSphere Platform Messaging (WebSphere Application Server, WebSphere ESB and WebSphere Process Server) or connect to WebSphere Brokers using the Real-time transport!
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.
With WMQ, an IBM Java environment is shipped with a number of platforms. If you’re developing JMS or WMQ Java Classes Client applications, it is well worth taking the time to scan the Diagnostics Guide that is available on developerWorks.
To give you an idea of the type of things this contains..
Java Heap Dumps- information on how to (a) produce one of these dumps yourself, and (b) how to understand the output. These can be very useful if you have a thread lock and need to work out what is locking what
Class Loading - Every wondered where that class was being (or not being) loaded from? Try this out.
Apologies for the slighly non-WMQ post.. but I thought this is very valuable information. Most WMQ users will be using a IBM JVM (or not?? please correct me!)
I saw Dale’s Diagnosing Triggering Problems post, and thought I’d add a checklist I put together.
The idea was to give some help diagnosting common triggering issues when setting up a new triggered queue for an app-team, or diagnosing a queue-depth alert at 2am on a callout.
The Conditions for a Trigger Event section in the APG is the definitive reference, but this checklist is written more from a diagnosis point of view.
The document has a UNIX bias I’m afraid…
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.
If you have trouble remembering what messages are included and excluded from the CurrentQDepth of a queue, the easy way to remember is that we expect all units of work to commit. So it goes down as soon as you do an MQGET, and it goes up as soon as you do an MQPUT.
The CurrentQDepth documentation in the Application Programming Reference does describe this but to my mind it reads like a set of rules to be learned. I remember things much better when given a model that I can understand.
CurrentQDepth is the number of messages currently on the queue. It is incremented during an MQPUT call, and during backout of an MQGET call. It is decremented during a nonbrowse MQGET call, and during backout of an MQPUT call. The effect of this is that the count includes messages that have been put on the queue within a unit of work, but that have not yet been committed, even though they are not eligible to be retrieved by the MQGET call. Similarly, it excludes messages that have been retrieved within a unit of work using the MQGET call, but that have yet to be committed.
The count also includes messages that have passed their expiry time but have not yet been discarded, although these messages are not eligible to be retrieved. See MQMD Expiry for more information.
Unit-of-work processing and the segmentation of messages can both cause CurrentQDepth to exceed MaxQDepth. However, this does not affect the retrievability of the messages; all messages on the queue can be retrieved using the MQGET call in the normal way.