For more details please go to MQGem Education and Training
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.
(@JensDiedrichsen) March 16, 2018
Read these links of interest:-
- IBM MQ on IBM Cloud, IBM MQ and IBM MQ Appliance 9.0.5 Continuous Delivery Releases are available
- Putting out a new release like IBM MQ V9.0.5 is more than a 9-5 job
- MQ 9.0.5 – Quick Start with MFT REST APIs
- Changes to CSRF protection in the MQ REST API in 9.0.5
- MQV9.0.5 – MFT REST API for Agent Status details
- New for MQ appliance – combine floating IP with aggregated links for maximum availability
- Easy Disaster Recovery with IBM MQ Advanced 9.0.5
A few days later, the next continuous delivery release on the NPE NonStop platform was also released. Read more about that here.
(@JensDiedrichsen) March 23, 2018
We’ll collect up any other links about the new release as we find them and put them all here.
For more details please go to MQGem Education and Training
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.
This 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:
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.
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.
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:-
- QM Logs
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.
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:-
DEFINE CHANNEL(MORAG.TO.MQG1) CHLTYPE(SDR) TRPTYPE(TCP) + CONNAME('mqg1-xxxx.qm.beta.mqcloud.ibm.com(nnnnn)') + XMITQ(MQG1) DEFINE QLOCAL(MQG1) USAGE(XMITQ)
And defined a receiver channel on my IBM Cloud queue manager, thus:-
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.
And then my inbound channel was able to run successfully
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 192.168.1.113. 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 192.168.1.113. You can change the port number at the same time, but I’ve kept it simple and used the same port internally and externally.
Now when I start my sender channel from my IBM Cloud queue manager to the queue manager on my own machine, it connects successfully.
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.
You can learn more with these resources:-
When you read the description of this new service in the Bluemix catalog, you’ll see it says the following:-
Manage MQ your way
Manage your cloud-based queue managers with the tools you know and love – including MQ Explorer, the MQ Console, or via MQ Script Commands (MQSC).
Once you have created your MQ on IBM Cloud Service and Queue Manager, as shown in the above video, and your queue manager is up and running, you’ll have a view something like this.
Click on the three vertical dots on the right of your queue manager to “Download Connection info”, or alternatively view the details of your queue manager and then there is a button there too which allows you to download the “Connection Information”. Either way, you’ll be presented with a pop-up which allows you to download a plain text file which contains the queue manager name, hostname, port number and a couple of channel names, one called an Application Channel and one called an Administration Channel.
In order to remotely connect to your IBM Cloud queue manager you will also need to be able to log in. As the MQ on IBM Cloud documentation describes here, you need the API key as your password to go with the user id ‘admin’. Follow the instructions on that page to obtain your API key.
Now you have all the pieces of information you need to set up any of the MQGem Software tools to administer your queue manager on IBM Cloud. As a reminder, these are the things you will need.
|Queue Manager Name||You invented it when you created the queue manager. If you’ve forgotten it, it’s also in the text file you downloaded with the connection information.|
|Channel Name||The “Administration channel name” can be found in the text file you downloaded with the connection information.|
|Connection Name||This is built by concatenating the “Hostname” and “Listener port” details (with brackets round the port number) that can be found in the text file you downloaded with the connection information.|
|User ID||This is ‘admin’|
|Password||This is the API Key that you created by following the linked instructions.|
On the pages that follow, we cover how to use the above information you have gathered in your table to configure each of our tools to connect to your IBM MQ in IBM Cloud Queue Manager. Go directly to the page for the tool you want to use, or page through each one in turn.
If you don’t have a licence and would like to try out any of our tools then send an email, noting which tool you’d like to try, to email@example.com and a 1-month trial licence will be sent to you.
I’d seen Jen’s Blog Post: Experimental service for MQ on IBM Cloud is here and watched the YouTube video: 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:-
Woz Arshad (@AverageWoz) January 19, 2018
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:-
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: 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.