You are currently browsing the monthly archive for May 2007.

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,

Read the rest of this entry »


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:


* 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).

Read the rest of this entry »

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.

Remote administration using runmqsc 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.

Read the rest of this entry »