You are currently browsing the monthly archive for March 2007.
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.