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.

Read the rest of this entry »

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.

Read the rest of this entry »

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…

Read the rest of this entry »

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.

Read the rest of this entry »

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?

Read the rest of this entry »

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.

Read the rest of this entry »

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

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:

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

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 »

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?

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.

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

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.

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:

  1. Connect to remote queue managers over a client connection
    • rather than just local queue managers
  2. 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.

Read the rest of this entry »

Follow

Get every new post delivered to your Inbox.

Join 35 other followers