Friday, 5 September 2014

IBM WebSphere MQ - (l)user error with amqsput and clustered Queue Managers

So I've spent nearly four hours, working with a much more experienced ( with WebSphere MQ ) colleague, trying to diagnose an issue.

In essence, I was trying to test the connectivity between WebSphere MQ ( WMQ ) and IBM BPM, and had configured BPM ( actually WAS ) to connect to a WMQ Queue Manager / Queue via an Activation Specification.

I had a sample Message Driven Bean (MDB) ( taken from this White Paper Using WebSphere MQ V7 as JMS Provider for WebSphere Application Server V7, V8.0 and V8.5 ) running inside WAS, and was expecting to be able to post a message onto a WMQ Queue hosted on a clustered Queue Manager, and have the content of the message appear in the WAS SystemOut logs, via the MDB.

I'd previously used the MDB in this manner, and all was well.

This time around, I kept seeing the following exception: -

MQCONN ended with reason code 2058

whenever I tried to post a message.

Now I was using the amqsput sample application that comes with WMQ ( I was using version 7.5 but it's also there with version 8 ), as follows: -

./amqsput Foobar Snafu

where Foobar is the name of the Cluster Queue Manager and Snafu is the name of the Queue.

Can you spot the mistake ?

No, neither could I, for nearly four hours :-(

We more-or-less reconfigured the entire WMQ cluster, including setting up a new non-clustered Queue Manager, refreshing the entire cluster infrastructure, restarting the Queue Managers several times. I nearly rebooted the LPARs upon which WMQ was hosted before .....

I reread this IBM Technote: -

for the umpty-leventh time: -

and noted the sequence: -

amqsputc SVR.LQ SVR

where SVR is the Queue Manager.

Yep, you've got it ....


"...where Foobar is the name of the Cluster Queue Manager and Snafu is the name of the Queue..."

So I should've been running: -

./amqsput Snafu Foobar

So my colleague nearly bashed me over the head, but, to be fair, he missed it as well, so I think we are even-stevens.

Simples :-)

No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...