MQ Devt Team Memories

The recent IBM MQ 25th Birthday celebration video that Hursley just released had a variety of photos from over the years in MQ Development. Unfortunately I’m not in any of them, but they did bring back memories of many of the people I worked with. One of the photos with the most people I recognised was the one below which you can see at 1m2s into the video. My guess is it was taken maybe 3 years before I joined the department, which would make it 1993. Perhaps it was the “V1 release” photo in 1993?

They are all making ‘V’ signs, which I assume is V for Victory, since Victory was the code name for the MQ for MVS; OS/390; z/OS product.

MQ Development Team

MQSeries for MVS/ESA Development Team (what Year?)
Click on the photo to enlarge

I can’t remember all the people in the photo, but I thought it might be nice to see whether others could help me fill in the gaps. And does anyone know where they all are now?

Back Row: Francis Burgess, Simon Rushton, Mick Lickman, Bob Gold, John Barfield?, Colin Paice (retiring 2018), Marilyn Rayner, Steve Craggs, ?, Andy Hebb, Gill Curwen, Lynn Barker
Middle Row: Joy Matthews, ?, Richard Appleby, Annabelle Chilton, Helena Smith, Terry Learney, Linda Taylor (my first manager), Dave Ashford, Dermot Flaherty, Anthony O’Dowd, Bryan Lewis, Ian Turner
Front Row: Keith Andrews, Keith Taylor, Dave Challis, Clare Sprenger, Jane Doel-James, Norman Adlam, Peter Missen, ?, Judith Bedford, Paul Kettley, Dave Coakley, John Jones
Front Row (Partial): ?, Paul Fairburn, Lionel De Lambert


IBM MQ and MQ Appliance News – March 2018

On Friday March 16th, IBM Hursley made available the next in the series of Continuous Delivery releases for IBM MQ V9.0 and the MQ Appliance. IBM MQ V9.0.5 is now available.

Downloading IBM MQ Version 9.0.5 Continuous Delivery

Read these links of interest:-

A few days later, the next continuous delivery release on the NPE NonStop platform was also released. Read more about that here.

We’ll collect up any other links about the new release as we find them and put them all here.

I can haz error logs?

IBM MQ on IBM Cloud has now reached the Beta phase. See Jen’s latest Blog Post: MQ on IBM Cloud – we’ve hit beta and one of the new things in the beta is the ability to view your queue manager’s error logs.

I Can Haz Error LogsThis is a very important step since one of the first things you should learn is how to discover what your queue manager is trying to tell you when there is an error. In fact this is one of the most important things my MQ training modules also teach you.

Here’s a quick summary of exactly how you can view your IBM Cloud queue manager error logs.

Having created your queue manager, as per Woz Arshad’s YouTube video:

YouTube Introducing MQ on IBM Cloud

you can view your queue manager and get connection information on how to connect to it. From this same view you can also get hold of your queue manager’s error log. Select the “Logs and diagnostics” option.

IBM Cloud MQ Logs and Diagnostics

Select the Logs and diagnostics section

This will show a panel where you have two choices. You can download a smaller zip file which is mainly about obtaining your error logs, or you can go for the full RAS package. For just the error logs click on the “Collect logs” button, and you will then be prompted to supply a password which you will use to unlock the error log files in the zip you download.

IBM Cloud MQ Collect logs

Press the button to collect the queue manager error logs

IBM Cloud MQ Download Log file zip

Download your password protected zip file

After a few moments your zip file will be ready and then you can download it to view the contents.

Inside the zip file there will be three folders:-

  • FDCs
  • QM Logs
  • trace

You’ll be interested in the folder called “QM Logs”. N.B. This is the error logs from the queue manager not the transactional logs.

Inside that folder you will find three files AMQERR0n.LOG – usually you will find all you need in AMQERR01.LOG.

IBM MQ on IBM Cloud – MCA Channels

One of the first things I wanted to do with my new IBM Cloud Queue Manager was to make channels to/from another queue manager on my own machine. Here are some tips that I learned from doing that. Screenshots below show the MQ Console making MQ objects, but of course you can also use all your favourite tools to manage your IBM Cloud queue manager.

Inbound Channel to an IBM Cloud Queue Manager

So I defined a sender channel and transmission queue on the queue manager on my own machine, thus:-

       CONNAME('') +

And defined a receiver channel on my IBM Cloud queue manager, thus:-

IBM Cloud MQ Console Create Receiver

Create a Receiver channel using the MQ Console

Starting the sender channel on my own machine, targeting my IBM Cloud queue manager failed with:-

AMQ9558: The remote channel 'MORAG.TO.MQG1' .. is not currently available.

Turns out you also need to allow this receiver channel through CHLAUTH. IBM Cloud queue managers come with a back-stop rule already in place, unlike any queue manager you have created yourself using crtmqm. Once you know this, it is a simple matter to get the channel running.

I created a CHLAUTH rule on my IBM Cloud queue manager. I chose to make a Queue Manager Map and not to put an Address filter on it because of all the network translation that goes on between you and your IBM Cloud queue manager. Perhaps later I’ll look into the address the queue manager thinks I’m connecting in from to add an Address filter to my inbound check.

IBM Cloud MQ Console Create CHLAUTH

Create a CHLAUTH rule to allow my receiver in

And then my inbound channel was able to run successfully

IBM Cloud MQ Console Running Channel

And now my receiver is running

Outbound channel from an IBM Cloud Queue Manager

If you have an external IP address for your own machine then you should be able to just plug it into the CONNAME of a sender channel on your IBM Cloud queue manager and get going as you might expect.

If you’re trying this out from home, you may well be behind a router, and using the ipconfig command (or equivalent) will only tell you the IP address assigned to your machine internally, e.g. if it’s a 192.168.* address it’s an internal private address and external connections such as the channels coming out from your IBM Cloud queue manager cannot see it.

One way around this is to use a VPN – if you have one for dialing into work when you are working from home that may well be enough. If you run it and then try the ipconfig command (or equivalent) again, you’ll see that you now have an external IP address. It’s likely that your IBM Cloud queue manager can see that address.

Without a VPN

One of the reasons I decided to write this part of the blog post, is that I think IBM Cloud queue managers may mean that more people are trying to connect between them and a ‘home’ address. Trying out MQ in the cloud is free at the moment, and may well encourage lots of people to try it out.

If you don’t have a VPN, and you are behind a router with a 192.168.* address, you do still have an external IP address, and you can find out what it is by asking google (or using a variety of other websites that will also be listed by this search).

If using your external IP address and queue manager’s port number still don’t work, this is likely because you are behind a router that doesn’t know what to do with this inbound connection. It doesn’t know to send it to your computer rather than any other computer on the internal private network.

You’re better off to have a static IP address for your machine when doing the following to save you having to continually make changes to this configuration every time the DHCP server gives you a new IP address, but it is not absolutely essential. My internal IP address in the following examples is You need to configure your router to tell it where to send connections that come in on the port in question, in the following examples, my queue manager is listening on port 2222.

All routers are different, but you’ll find some kind of section, probably in an advanced setup section, that mentions NAT Forwarding. In that section look for something like Virtual Servers, and then add in configuration that tells the router when it sees traffic on your external IP address and the port your queue manager is listening (2222 in my example), to send that on to the machine with internal IP address You can change the port number at the same time, but I’ve kept it simple and used the same port internally and externally.

IBM Cloud Router config

Configuring my router to pass on connections targeted for my queue manager

Now when I start my sender channel from my IBM Cloud queue manager to the queue manager on my own machine, it connects successfully.

IBM Cloud MQ Console Two Running Channels

Now both my channels, inbound and outbound, are able to run

Since you’ve opened up a port to the outside world to get your channel running into your own machine from the IBM Cloud, you’ll now be able to see the IP address it comes in from. You may want to add an IP address filter with a CHLAUTH rule so that only your cloud queue manager can make that connection.

The next thing I’d like to see from the MQ on IBM Cloud team is how to use SSL/TLS on my channels.

Getting going with MQ on IBM Cloud

I’d seen Jen’s Blog Post: Experimental service for MQ on IBM Cloud is here and watched the YouTube video: YouTube Introducing MQ on IBM Cloud and thought I would have a go. Anything that allows me to try out an MQ queue manager in a different way, I’m interested in trying.

I’m new to Bluemix and IBM Cloud but I had an IBM ID already, so I signed up with my IBM ID and got an IBM Cloud account. Then I went to the catalog page for the new Experimental IBM MQ service and it told me I needed to upgrade my account before I could use it. Upgrading my account required a Credit Card. I was initially dubious about this – the catalog description clearly stated this was free!

I asked on Twitter and Woz kindly answered:-

So I bit the bullet and added my Credit Card details. Now I’d be able to make a queue manager!

Unfortunately not. Now the catalog page had another error:-

You don’t have access to any organizations or spaces in this region. Check that you have the appropriate access with your account owner or administrator.

IBM Cloud Region Access Error

I emailed for help to the address in Jen’s blog post, and was told this was caused by not having a Cloud Foundry Org and Space set up in the “US south” region. Here’s how you fix that:-

  • Assuming you’re logged into IBM Cloud look for the Manage menu in the top right of your screen. Choose Manage -> Account -> Cloud Foundry Orgs
  • There will probably be one entry in the list named after your email address. If there’s nothing listed there, click on the big blue button “Add a new Cloud Foundry Org” and give it a name. If you have an entry on the list, click on View Details on the existing entry.
  • The details shown will show the region your Cloud Foundry spaces are in. If the region is not “US SOUTH” then that is why you see the above error. Click on “Add a Cloud Foundry Space” and ensure you choose the region as “US South”, give it a name and add it.
  • Now go back to the MQ catalog entry and the error should have gone away.

Now you can follow along with the steps in the YouTube video: YouTube Introducing MQ on IBM Cloud.

I’m told the MQ on IBM Cloud documentation here is going to be updated to include something similar to the above.

UPDATE: I hit one further problem later on. My API Key password that I was trying to use to log into the MQ Console never worked. I tried lots of different things, and had a few emails with IBM Hursley, before it was found that there was an intermittent authorization problem in IBM Cloud. This was fixed and after that my password worked exactly as the instructions said it should. This was an intermittent problem but I wasn’t the only person to hit it (see question in dWAnswers). If you also hit this problem, I suggest to go back and try it again now that this has been fixed.

Conference Material from 2017

There have been quite a number of events throughout 2017 that have had IBM MQ content delivered at them. I hope you were able to attend at least one. The presentation material is online for many of these events, and download links are shown below where we are aware of them.

Behaviour changes in MQ V9.0.4 – CONNAUTH/CHLAUTH

UserID and PasswordIBM recently released it’s latest Continuous Delivery release (MQ V9.0.4). This has made some changes to the default behaviours for CONNAUTH and CHLAUTH. You can read all the new changes in V9.0.4 here, but I wanted to highlight a few I thought were very important.

Adopt Context is YES by default

From the introduction of Connection Authentication in IBM MQ V8, the default value of ADOPTCTX was NO. I am delighted to see that the default has now been changed to YES. This is probably the most common configuration problem we help customers with around the use of Connection Authentication. It’ll take a while to percolate through, because there are plenty of existing queue managers out there with ADOPTCTX(NO) but it will definitely improve things.

qm.ini ChlauthEarlyAdopt=Y is now the default

The qm.ini ChlauthEarlyAdopt attribute was added in IBM MQ V8 FixPack 5 to allow users to revert the behaviour back to the way it was prior to another change that was made – i.e. back to the designed IBM MQ V8 GA behaviour. I am very happy to see that IBM has now reverted this behaviour to be there by default for everyone.

Java clients use user ID and password in the same way as ‘C’ clients

Due to the historical use by the Java client of the FAP flow to send a user ID and password (as described in this blog post) a compatibility setting had to be provided at MQ V8 GA in case any Java Client connections into queue managers were relying on this behaviour for their security exits. This meant that Java clients and ‘C’ Clients operated differently by default. Now, as of V9.0.4, the Java client uses the MQCSP to send its user ID and password just as the ‘C’ client does and they both work the same way. This is very good news.