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.

WebSphere MQ v5.3 Explorer

The v5.3 Explorer provides the ability to export it’s connection information. Right-click on “Queue Managers” and click on “Export List…”.
For my purposes, I exported a list as “Comma Delimited” text (as I thought it’d be easier to work with).

The file looks something like this:

Name,Local/Remote,Remote Connection Name,Queue Manager Status...
QM1,Local,,Stopped,Not Connected,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
QM2,Local,,Stopped,Not Connected,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
QM3,Local,,Stopped,Not Connected,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
RQM1,Remote,dlane.hursley.ibm.com(9099),Unavailable,Not Connected,,,

I'm only really interested in the first three fields - queue manager name, whether it is local or remote, and (for remote queue managers) the connection name.

WebSphere MQ v6 Explorer

I found an XML file WMQ_Handles.xml under my APPDATA directory which contains the connection information for queue managers shown in my v6 Explorer. It can be found at:
%APPDATA%\IBM\MQ Explorer\.metadata\.plugins\
com.ibm.mq.explorer.ui\WMQ_Handles.xml

The file is fairly human-readable, and by creating a few connections in WMQ Explorer to populate the file it is easy to work out what it should contain.

After doing that a couple of times, I had enough information to write a quick app to convert the csv file exported from the v5.3 Explorer to this new XML format. I chose to write this in Java, but it could easily be converted to pretty much any language.

You can download the code listing for my simple app here.

This seemed to do the trick for my needs, and produced a new WMQ_Handles.xml file populated with all of the connection information I had in my v5.3 WMQ Explorer.

I closed the v6 Explorer, overwrote the XML file with my new one, and restarted it so that it would pick up the new connections settings.

Things to note

Note 1: You should trust the code above as much as you would trust any code written in 20 minutes for a single specific purpose! Or in other words, it worked for me but your mileage may vary. The XML generated was consistent with the XML data that my copy of WMQ Explorer is currently using, but there is no guarantee that the format of this file will not be changed in future maintenance updates.

You would be better off using it as a starting point for your own investigation rather than seeing it as a complete solution.

Note 2: If you are worried about losing any existing connection information, please backup the WMQ_Handles.xml file before you overwrite it! That said, if it all goes horribly wrong, you can just delete it and a new XML file will be created the next time you start WMQ Explorer.

Note 3: Is this recommended?

As a general rule, going to the underlying files where WebSphere MQ stores data and manually editing them yourself is not an IBM-recommended approach!

That said, for my purposes, it did the trick - if there were problems with the conversion of any individual connections I could always delete the problem connection(s) and manually define a valid one from inside WMQ Explorer. Even if I had to do that a few times, it would still be an improvement on having to re-define all of my connections. And if there were problems with most/all of the connections, I could always restore the original WMQ_Handles.xml file (see Note 2 above), and just go back to defining connections manually inside WMQ Explorer.

Ultimately, please remember that this isn't an IBM website. If you use this and it works for you, fantastic. If you use it and it leads to problems with the connection in WMQ Explorer, delete the connection and recreate it manually, as you may not get much support for problems with a manually hacked settings file!