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:
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.
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.
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 :
Set-WMQ. Where things get interesting is in combining them through the use of the object pipeline.
On Tuesday, I discussed creating new WMQ objects from PowerShell. Today, I want to talk about how to modify existing WebSphere MQ objects.
On Monday, I discussed getting WMQ objects with PowerShell. Today, I want to talk in more detail about getting specific objects into 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.
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.
Once installed, see the man pages ibm.com-WebSphereMQ(8) 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.