The developerWorks Connections platform, which hosted the MQDev Blog, was sunset as of 31st December 2019. The blog post below was something I wrote previously on that platform, and since I consider it to still be useful, I am now hosting a copy here. It was originally written in 2015, but I have updated it for 2021, and again for 2023. View all saved from sunset posts here.
It’s that time of year again, New Year. Time to make New Year’s Resolutions. Here are a few IBM MQ related New Year’s Resolutions you could adopt for this coming new year.
Remember to look in your error logs
This is top of the list because it is so often forgotten about by so many MQ users. If you look at questions raised about IBM MQ on the various forums out there, there are many questions where the answer would have been found in the error log. There are error logs at both the client machine and the queue manager machine where you have a problem with a client connection – always look in both. There are error logs are both ends of MCA channels – always look in both.
Use MQRC return codes
IBM MQ provides error information to applications via a Return Code on the MQ API call. These numbers are of the form 20nn. Some of them are very familiar to us, but others are seen rarely. Get to know the common ones. You can look them up using the mqrc tool that comes with your MQ installation. Your applications should handle certain common MQRCs and not simply end as soon as a non-zero MQRC is encountered. Doing so will avoid call-outs in the middle of the night to restart an application that received a 2009 (MQRC_CONNECTION_BROKEN) or worse a 2033 (MQRC_NO_MSG_AVAILABLE)!!! Resolve to teach your application developers how to handle the common ones in the application, and to log anything they don’t handle. And remember, Java programmers, we want to see the linked exception!
MQ API resolutions
Resolve to ensure that your MQ application programs follow all the below as appropriate.
- Don’t leave syncpoint to the default value. Always explicitly state MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT and utilise MQGMO_SYNCPOINT_IF_PERSISTENT where possible.
- Don’t rely on the default persistence value set on a queue (DEFPSIST), set it explicitly in your application. And while we’re on the subject, does your message really have to be persistent?
- Have you set an expiry value? Does your message really have to live for ever? Perhaps you can utilise CAPEXPRY until your application can be updated, especially now that it is a real attribute.
- Remember to set the format of your messages correctly. If it’s a string message, say so. And ensure that getting applications always use MQGMO_CONVERT. There is no penalty for this if no conversion is required, and it’ll save you pain in the future when conversion does become necessary.
- Watch out for MQCONN-MQOPEN-MQPUT-MQCLOSE-MQDISC loops. Get familiar with application activity trace to find whether you have applications doing this.
Use a Dead-Letter Queue
In much older releases of MQ, there was an all-or-nothing configuration for the Dead-Letter Queue. If you had one single application that couldn’t suffer the possibility of out-of-order messages on its channel due to a detour through a Dead-Letter Queue, you couldn’t enable the DLQ for any other applications and their channels either. In all in-support releases of MQ there is an attribute both on a Channel and on a Topic to indicate that you want to use (or not use) the DLQ for this specific item. That attribute is USEDLQ( YES | NO ). Make this the year you enable the Dead-Letter Queue now that you can choose which channels will make use of it. Learn where channels make use of the DLQ in this recent post.
Protect against run-away client connections
Make use of MAXINST and MAXINSTC to protect your queue manager against runaway client connections that connect repeatedly, but do not disconnect. Read more about this in a post saved from sunset.
Enable IBM MQ Security features
When MQ V7.1 first delivered CHLAUTH, many of you, initially, disabled it just to be able to continue working as before. MQ V8 delivered CONNAUTH and I’m sure that was turned off by many too. Lots of you aren’t making use of message level encryption with Advanced Message Security.
These features have had a few releases to bed in now, and if you’re not making use of them, it’s time to think about them now. Security of your MQ Queue Managers is very important! Make this the year your fully secure your queue managers.
Stop using SSL V3.0 and TLS V1.0
MQ Channel cipherspecs should be regularly reviewed and upgraded to more modern, stronger algorithms. Make this the year you review all the cipher specs you have in use and change them to be a TLS V1.2 or higher one. Even if you’re not yet using a version of IBM MQ that deprecates these protocols by default, you should consider the fact that they are deprecated in those newer releases as a strong hint to stop using them. See the full list of MQ Channel cipher specs and which protocol they make use of in IBM Docs: Enabling CipherSpecs.
Finally enable MQ Events, Accounting and Statistics
The IBM MQ Queue Manager can be configured to emit lots of useful information in the form of event messages and accounting and statistics data. Make 2023 the year you finally turn on these features and get the benefits from them. We know many of you keep meaning to get around to it. It’s not hard, and is made easier with a helpful tool to view the data. We have one if you’re interested!
Use modern versions of IBM MQ
Make this the year that you migrate onto IBM MQ V9.3. Version 8.0 went EOS on 30th April 2020, Version 9.0.0 went EOS on 30th September 2021 and Version 9.1.0 went EOS on 30th September 2023. (View MQ EOS dates here). You can migrate straight to IBM MQ V9.3 without first jumping to another release from V8 and upwards (read more here). If you want to learn more about the new features in IBM MQ V9.2 and V9.3, check out these new MQGem Training courses.
Don’t forget client versions
It’s harder to manage than your queue manager versions, but resolve to get all the old clients in your system identified, and work on persuading them to upgrade. Use the information that IBM MQ provides to find all those old client versions.
Participate in the MQ community
The IBM MQ community is a great crowd. You can learn so much from the many expert users in the field. If you are stuck with a question, ask it on one of the many fora dedicated to MQ. Interact with IBM by raising an IDEA if there is a change you would like to see made to the product; and socialise your IDEA on the fora to gain votes from others who agree with you. Use IBM Docs to discover how to use MQ, and provide feedback to IBM whenever you find anything incorrect in the documentation.
Learn something new about MQ
Every release of IBM MQ comes with new features. Is your level of MQ knowledge up-to-date? Make a resolution to try out a new feature that you have never used before; attend a training course; or go to a technical conference for some education.
Have you any other suggestions? Made any New Year’s resolutions already this year? Let us know, and everyone else see, in the comments below.
This post is to highlight the Virtual User Group on May 19th and 20th. I’ve seen various posts about it, and it seems to be a combination of several different User Groups who are all unable to hold their usual in person conferences. This includes the IBM WebSphere User Group (UK) and the IBM Integration User Group (UK).
MQGem Software 