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.
The newest version of MO71 is able to check what the latest available maintenance level of IBM MQ and inform you if you are back level.
In its simplest form this comes as a file menu option which you can manually select at any time. However there is also an option to have MO71 check for new versions automatically to save you having to remember to do it, and to pop up a reminder to you if there is a new maintenance level.
In addition, if you run a HealthCheck on your queue managers, one of the problems that can be checked for is whether your queue manager is running at the latest maintenance.
And finally if you look at a multi-queue manager list of queue manager attributes, there is a new column that can be added to this display which shows the latest maintenance applicable to the version each queue manager is using. If a queue manager is up-to-date on maintenance then this field is blank. Therefore, a simple filter showing only those rows with something in that field can immediately show you which queue managers need maintenance applied, or you can make a simple filter to highlight the queue managers that have a newer MQ maintenance level available, by changing their background colour, as shown below.
The new version can be downloaded from the MO71 Download Page. Any current licensed users of MO71 can run the new version on their existing licence. If you don’t have a licence and would like to try out MO71 then send an email to firstname.lastname@example.org and a 1-month trial licence will be sent to you.
In this post we look back on the year that was 2017 and what happened in both IBM MQ, and MQGem Software.
Both IBM MQ and MQGem Software products had a number of new releases in 2017.
MQGem Software products
Three new versions of our premier product, MO71 – a graphical administrative product for IBM MQ. Version 9.0.3 was released in March with various new features including the very popular hostname display for your IP addresses, and User Commands. Version 9.0.4 was released in July with the Activity Trace viewer being its main feature, and then version 9.0.5 was released in August to supply the new column filters feature.
In January of 2017 we also made available the ability to run Microsoft Windows graphical programs such as MO71 and MQEdit which use IBM MQ libraries, on Intel Linux under Wine.
An MQSCX mini version 9.0.1 was released in July with some customer requested features.
Two new versions of QLOAD – our unload/load IBM MQ queues product, were released this year. Version V9.0.1 was released in June with the capability to unload and reload all your queues at once. Then version V9.0.2 was released in July with a customer requested feature providing rated throughput.
Our newest product MQEdit – a live-parsing IBM MQ message editor – also had a new version this year. Version V9.0.2 was released in August providing several more natively understood formats, as request by customers.
IBM MQ Fix Packs and new function
Two new Fix Packs on IBM WebSphere MQ V7.1. Fix Pack 126.96.36.199 was released in January and the last Fix Pack on this release, Fix Pack 188.8.131.52 was released in November. One new Fix Pack on IBM WebSphere MQ V7.5. Fix Pack 184.108.40.206 was released in July.
There were also three new continuous delivery (CD) releases made available in 2017. V9.0.2 in March, V9.0.3 in May, and V9.0.4 in October. Only the two most recent CD releases are still in support. With each CD release to date, the MQ Appliance has also been available at that level. In addition to the new versions on the MQ Appliance, IBM released support for external storage on the MQ Appliance.
There have been quite a number of events throughout 2017 that have had IBM MQ content delivered at them. A separate post contains all the material that is available on-line from these various events.
There have been some really great blog posts written throughout 2017. Lots of the guys in IBM Hursley have been blogging about the new features they have been releasing throughout the year. They have a new blog to host all their posts with the creation of IBM Messaging for admins and developers.
2017 has been a great year for all things MQ. MQGem wishes all its customers, readers, and friends a Happy and Prosperous 2018. HAPPY NEW YEAR!