IBM MQ and MQ Appliance November News

IBM Hursley has made some recent announcements.

Downloading IBM MQ Version 9.0.1 Continuous Delivery

Links to the announcement letters are below.

Alternatively, read about the changes in these blog posts by Leif Davidsen.

Other links of interest:-

Or watch this video.

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

The next Continuous Delivery (CD) release is now available. Read more about V9.0.2.


Which channels are being used?

Which ChannelIt was asked recently on the List-Server whether there was an easy way to determine which MQI channels were being used. The asker also raised an RFE to request Channel Statistics be output by the queue manager for these channels as well as the MCA channels that do currently have statistics.

While that facility would indeed help to show which channels were being used, and for what amount of time/traffic and so on, if the problem at hand is only to determine which channels are used and which are not, for example so that unused ones can be deleted, then a current facility of the queue manager is available to discover that.

The Channel Authentication (CHLAUTH) rules which block connections into the queue manager have two modes, blocking and warning. This is controlled by the WARN(YES|NO) attribute. This was briefly discussed in my blog post CHLAUTH – the back-stop rule, to alleviate any concern of initially blocking all connections into a currently working queue manager.

Now here’s another use for WARN(YES).

If you already use CHLAUTH and already have a back-stop rule that covers all channels, then you know that only those you have positive CHLAUTH rules in place for can be being used.

If you don’t already use CHLAUTH, or at least your use of it is not applied to all channels, you could put a rule very similar to the back-stop rule in place, but using warning mode, and then see which channels are being used over time.


Alternatively, if you’re just trying to figure out if a specific channel (or channels) is actually ever used, you could make the rule specific to that channel name.


Either way, to see useful output from this, you should enable channel events, and monitor for the event messages emitted by the queue manager.


Here’s an example event message that would be seen by a channel called MORAG.SVRCONN connecting into the queue manager. As you can see, you are shown the channel name, connection name (i.e. the IP address where the client resides), the client side user id and the application name (in this case q.exe). All very useful for working out what it was that ran and caused this channel to be used.

[  224 bytes] Message Content
[  224 bytes] Event Header (MQCFH)
Version      :1
Command      :46 (Channel Event)
Sequence No. :1
Reason       :2578 (Channel Blocked Warning.)
Parm Count   :7
[  188 bytes] String (MQCFST)
Parameter Id :2015 (QMgr Name)
String Length:4
Value        :'MQG2'
[  164 bytes] String (MQCFST)
Parameter Id :3506 (Connection Name)
String Length:9
Value        :''
[  132 bytes] Integer (MQCFIN)
Parameter Id :1020 (Reason Qualifier)
Value        :23 [0x'17'] MQRQ_CHANNEL_BLOCKED_NOACCESS
[  116 bytes] String (MQCFST)
Parameter Id :3501 (Channel Name)
String Length:13
Value        :'MORAG.SVRCONN'
[   80 bytes] String (MQCFST)
Parameter Id :3567 (Client User Id)
String Length:5
Value        :'morag'
[   52 bytes] String (MQCFST)
Parameter Id :3024 (Appl Name)
String Length:16
Value        :'d:\nttools\q.exe'
[   16 bytes] Integer (MQCFIN)
Parameter Id :1 (Appl Type)
Value        :11 [0x'B'] MQAT_WINDOWS_NT

N.B. When trying this out for yourself, if you truly only want a logging style use of CHLAUTH and you don’t want anything else to be affected while you do this, including SYSTEM channels and remotely asserted privileged user ids, then you’ll have to first remove the default provided CHLAUTH rules.

I was prompted to write this post as a result of this list-server question.


I got asked this question on twitter the other day, so I thought it would make an interesting blog post.

Let’s look at each piece of the question.


You can use the DISPLAY QMSTATUS command to see how many connections there are currently made into the queue manager. This is a count of the number of applications (or some queue manager processes too) that have made an MQCONN(X) to the queue manager. It is also the same number of responses you should see returned by DISPLAY CONN(*) – if you don’t want to count them, find an MQ admin tool that counts them for you. These connections might be local or client connections – both contribute to the total.

To see the local ones use command:-


To see the remote ones use command:-


Client Connections and MaxChannels

So having ruled out the local connections what should you think if the number of connections coming in over a channel is more than MaxChannels? As the question asks, “Shouldn’t that be failing?”

The other thing to remember here is that, since MQ V7, one SVRCONN channel can relay several client MQCONNs over to the queue manager.

To see this take a look at the DISPLAY CHSTATUS command. There is a status attribute CURSHCNV that shows the number currently being shared over that one SVRCONN instance.

To see the number of running channels, use the command:-


The number of responses will show you how many running channel instances there are – which is the number to compare against MaxChannels. If you add up the total of all the numbers shown in CURSHCNV, this total will be less than (or equal to) the above number of channel based connections shown when you used the DISPLAY CONN command. Both queue manager channels and client channels contribute to that total.

HINT: If you want an easy way to total up all the numbers shown in CURSHCNV, try out MQSCX with this single line:-

@total=0;foreach(DISPLAY CHSTATUS(*) CURSHCNV);@total=@total+CURSHCNV;endfor;print @total

Or you could make a little import file to print out all the various numbers:-

=echo cmds(NO)
=echo resp(NO)
print 'Show all the connections into queue manager',_connqmgr
print _sep

print 'Total connections ',CONNS

print 'Local connections ',_matches

print 'Remote connections',_matches

@total = 0
@svrcn = 0
    @svrcn = @svrcn + 1
  @total = @total + CURSHCNV
print 'Total Channel instances ',_matches
print 'QMgr Channel instances  ',_matches - @svrcn
print 'Client Channel instances',@svrcn
print 'Client connections',@total
=echo cmds(YES)
=echo resp(YES)

UPDATE: This script evolved further with the release of MQSCX V9.0.0 and the use of functions – see more in MQSCX Functions.

IBM Certified SpecialistIBM Champion 2016 Middleware

Morag Hughson
IBM Champion 2016 – Middleware
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: Twitter: SlideShare: developerWorks:

MQCCDTURL and mqclient.ini

During the process of writing my June IBM MQ Little Gem post over on IMWUC, I learned a bit more about the CCDT URL feature in IBM MQ V9 and how it works when you use an mqclient.ini file.

Jon Rumsey has a great write-up of this feature on the MQDev Blog, MQ V9 Client Channel Table Enhancements – URL retrieval, where he indicates that the equivalent to the MQCCDTURL environment variable is to use the ChannelDefinitionDirectory attribute in the Channels stanza of mqclient.ini.

mqclient.ini file for IBM V9My new blog post has a table of all the client environment variables and their equivalents in the mqclient.ini file (an update to a post I wrote in 2014). I noticed that the attribute that Jon refers to, ChannelDefinitionDirectory, is already in use as the equivalent to the MQCHLLIB environment variable.

I know that the MQCHLLIB environment variable only specifies the path to the CCDT, whereas the MQCCDTURL environment variable specifies the whole path and file name. So I wondered whether ChannelDefinitionDirectory was really the direct equivalent.

I had previously been using the following environment variable:-


so I tried out an mqclient.ini file with the following contents as a direct equivalent:-


and was rewarded by the following error in my AMQERR01.LOG:-

AMQ9795: The client channel definition could not be retrieved from
its URL, error code (16).

The client channel definition location was specified as URL
'', however the file could
not be retrieved from this location. 

The error returned was (16) 'HTTP response code said error'. The
protocol specific response code was (404).
Ensure that the URL is reachable and if necessary correct the details

404 is the standard HTTP “not found” response code, and it is not a surprise that it couldn’t find the file since it has concatenated the default AMQCLCHL.TAB file name on the end of what I provided. So it would seem that you need to use both ChannelDefinitionDirectory and ChannelDefinitionFile in the mqclient.ini file to get the equivalent behaviour to the MQCCDTURL environment variable.

With an mqclient.ini file with the following contents:-


I was able to successfully connect.

IBM Certified SpecialistIBM Champion 2016 Middleware

Morag Hughson
IBM Champion 2016 – Middleware
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: Twitter: SlideShare: developerWorks:

Translate from setmqaut to SET AUTHREC

IBM MQ on the distributed platforms have commands to grant authorities to groups and users, in order to allow them access to use resources on a queue manager. There are actually three command interfaces to do this.

  • setmqaut
    This was historically the first command interface. It is a control command, issued from the command line by a user who is a member of the mqm group.
  • Set Authority Record
    Next the PCF flavour of the command was implemented allowing the MQ Explorer (and other remotely connected tools such as MO71) to be able to issue these commands.
    Finally, and most recently, the MQSC flavour of the command was implemented, allowing authority commands to co-exist in scripts along with object definitions.

When using a queue manager on the MQ Appliance, there is no setmqaut command. You are expected to either use a GUI with the PCF commands, or the MQSC scripting language and a SET AUTHREC command. In general the queue manager on the MQ Appliance is just like any other queue manager, and you may well be following some instructions to set up something on your appliance queue manager, but those instructions only provide examples with the setmqaut command.

This post is going to help you translate from an example setmqaut command to a SET AUTHREC command.

Here’s a couple of example commands that cover all the main switches you might see on a setmqaut command (although not all the values).

setmqaut -m QM1 -t qmgr -g mqgadm +connect

setmqaut -m QM1 -t queue -n WORK.Q -p mqgusr -all +put +get

Sometimes it’s easier to see this sort of thing diagrammatically. So first I show a picture and then below is a table to step through each switch.

setmqaut mapped to SET AUTHREC

setmqaut mapped to SET AUTHREC

Here’s a table to map from setmqaut to an MQSC SET AUTHREC.

setmqaut SET AUTHREC Notes
setmqaut SET AUTHREC Instead of using the setmqaut command, you’re going to use the SET AUTHREC command.
-m QM1 runmqsc QM1 MQSC commands are directed to the queue manager your MQSC issuing tool, such as runmqsc is connected to, so it’s not part of the SET AUTHREC command, instead it’s the direction to runmqsc to tell it which queue manager to connect to.
-t queue OBJTYPE(QUEUE) The -t switch becomes the OBJTYPE parameter and it’s value could be exactly the same, except for cases when setmqaut uses shortened forms. For example -t q is the same as -t queue. If you know your IBM MQ object names from other MQSC commands, then you’ll have no trouble figuring out which one is which.
-n WORK.Q PROFILE(WORK.Q) The -n switch becomes the PROFILE parameter. It’s called a profile rather than an object name since it could have wildcards in it. The value that went with the -n goes inside the brackets. One thing to remember though, MQSC will upper case anything that you don’t put inside quotes, so if your profile name is not upper case, add quotes around it. In the case of -t qmgr, there will be no -n switch, and you can omit the PROFILE parameter.
-g mqgadm GROUP(‘mqgadm’) The -g switch becomes the GROUP parameter and the value goes inside the brackets. Remember to use quotes.
-p mqgusr PRINCIPAL(‘mqgusr’) The -p switch becomes the PRINCIPAL parameter and the value goes inside the brackets. Remember to use quotes.
-all AUTHRMV(ALL) Any authority switches with a ‘-‘ sign are being removed. These should go in the comma-separated list in the AUTHRMV parameter. It is often seen that -all is used because adding a few authorities, in order to remove everything before adding new ones so you know where you are. Normally you wouldn’t combine AUTHRMV and AUTHADD parameters, but the use of ALL is one of the cases where it is allowed.
+put +get AUTHADD(PUT,GET) Any authority switches with a ‘+’ sign are being added. These should go in the comma-separated list in the AUTHADD parameter. The authority switches are spelled the same in both setmqaut and SET AUTHREC, just remove the ‘+’ (or ‘-‘) prefix.

If you come across a setmqaut command that you can’t translate into a SET AUTHREC with the above instructions, add it in the comments, and I’ll help you out. It’ll also improve this blog post for others.

IBM Certified SpecialistIBM Champion 2016 Middleware

Morag Hughson
IBM Champion 2016 – Middleware
IBM Certified System Administrator – MQ V8.0
Find her on: LinkedIn: Twitter: SlideShare: developerWorks:

Recent IBM End of Support Announcements

There have been a number of recent End of Support (EOS) announcements that you should be aware of.

Using User ID and Password with a ‘C’ Application

“… but it works from MQ Explorer”

UserID and Password without V8It seems that the introduction of User id and Password checking in IBM MQ V8 is prompting many people to start looking at using User id and Password checking, even though they are not yet at V8. I’m sure this is a positive trend – unless of course it’s because people are throwing out SSL/TLS in favour of passwords – but that’s a story for a different time.

We’ve seen lots of discussions on this topic recently, with one common statement, “… but it works from MQ Explorer”.

‘C’ Applications vs Java Applications in IBM MQ

In the releases prior to IBM MQ V8 there are patchy mechanisms for using User id and Password checking, which can give you the same support as you get built-in at IBM MQ V8; but you need to be careful because they don’t all work the same way.

Used by Delivery Protocol QMgr-side Checks Examples
Java Client Historic FAP fields Security Exit pulling fields from the MQCD structure, RemoteUserIdentifier and RemotePassword CSQ4BCX3 Sample security exit shipped on z/OS
The MQAUSX Security Exit
‘C’ Client MQCSP across client channel Security Exit pulling fields from the MQCSP structure The MQAUSX Security Exit
Local Apps (dist) MQCSP across IPC Custom Authorization Service plug-in I’m not sure any vendor made one of these
Local Apps (z/OS) Nothing Nothing Nothing

One issue with the above that catches a lot of people out, is that they get a solution that works for the Java Client, for example the MQ Explorer, and then they find it doesn’t work with any ‘C’ Client applications, for example MO71. The sample exit, CSQ4BCX3 that is shipped with WebSphere MQ for z/OS is one such example.

User ID and password checking with IBM MQ V8

Lots has been written about Connection Authentication in other blog posts so I won’t reiterate all that here. You can read more by following these links:-

What I wanted to put in this section was the same table as above, but with the IBM MQ V8 Support, showing some of reasons why the Connection Authentication feature was needed.

Used by Delivery Protocol QMgr-side Checks
Java Client in Compatibility Mode Historic FAP fields Converted into MQCSP by the SVRCONN and driven through CONNAUTH
Java Client not in Compatibility Mode MQCSP across client channel MQCSP given to CONNAUTH
‘C’ Client MQCSP across client channel MQCSP given to CONNAUTH
Local Apps (dist) MQCSP across IPC MQCSP given to CONNAUTH
Local Apps (z/OS) MQCSP across PC call MQCSP given to CONNAUTH

As you can see the local applications on z/OS get provision in V8 where there was no prior solution, and there is a common solution between Java Clients and ‘C’ clients removing all that confusion in earlier releases.

Common solution without IBM MQ V8 everywhere

As you may notice from the above table, the architected delivery protocol for user id and passwords that can be common everywhere is the MQCSP. The way to get a common solution that can work for both Java and ‘C’ clients, and also future-proof you for when you move up to IBM MQ V8 in the future, is to base your solution on MQCSP.

The MQCSP structure was introduced into WebSphere MQ V6, so as long as your client and queue manager have that level as a minimum you can take advantage of that.

So you need something at the client side which can send an MQCSP for you. Your choices are:-

  • Use a WebSphere MQ V6 or above ‘C’ Client application
  • Use an IBM MQ V8 Java Client application with Compatibility Mode turned off
  • Use a client-side security exit, such as the mqccred exit shipped with IBM MQ V8 which you can use with older versions of the client. Some of the vendors that process MQCSP in a security exit on the queue manager side can also provide a client side exit to send an MQCSP – ask your vendor.

And you’ll also need something at the queue manager side which can receive and process an MQCSP for you. Your choices are:-

  • An IBM MQ V8 Queue Manager
  • One of the example Security Exits shown in the first table of this article, that process an MQCSP – so that rules out CSQ4BCX3, just to be clear.

You can mix and match these two lists as you need to.

Of course, there is one other thing to think about as you enable your user ID and password to flow from your client to your queue manager and that is to protect it as it flows across the network. Your choices are:-

  • Have a fully trust-worthy network!
  • Encrypt the connection, say with client-anonymous, one-way authenticated SSL/TLS
  • Have a pair of exits both sending and processing the MQCSP which also encrypt what they send – some vendor solutions offer this capability
  • Have IBM MQ V8 as the minimum at both ends, and the password will not be sent in the clear

Additional Resources

If you’re an exit vendor and would like your security exits listed in the above table, please get in touch, or leave a comment below and I’ll add you in.