You are currently browsing the monthly archive for February 2007.

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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?

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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!

xmsconsumer xmsproducer

Read the rest of this entry »

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.

Read the rest of this entry »

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 Dumpsinformation 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…

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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.

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.

Read the rest of this entry »