Worked Example: Solving MQRC_NOT_AUTHORIZED

MQRC_NOT_AUTHORIZED (2035) can result from a number of different causes (CHLAUTH rules, CONNAUTH settings, and missing Authorities). This post is going to provide a worked example of solving your MQRC_NOT_AUTHORIZED failure when missing authorities are the reason.

You might guess that it’s missing authorities because you have disabled CHLAUTH and CONNAUTH (please don’t – read this for another worked example for leaving those security features on), or because you have looked in the AMQERR01.LOG and seen a message like the following. If the latter, well done, you are already well on your way to solving the issue.

AMQ8077W: Entity 'mqgusr1' has insufficient authority to access object MQG2 [qmgr].

EXPLANATION:
The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: connect
ACTION:
Ensure that the correct level of authority has been set for this entity against the required object, or ensure that the entity is a member of a privileged group.

To fix this issue you are going to grant the missing authority. However, it is more appropriate to grant it using the group than the user id. So first, we should find out what group this user ID is in.

Discover group (Linux/Unix)

Issue a command like the following.

id -Gn mqgusr1

The output will be a list of the groups this user is a member of.

Discover group (Windows)

Issue a command like the following.

net user mqgusr1

You will see output like this.

Local Group Memberships      *mqgemadm             *Users

While the user may be a member of a number of groups, there should be one that is clearly the MQ related group name where these authorities should be granted. For the purposes of my example, this is a group called mqgemadm because I am trying to use this user id to connect to MQ and display some queues.

Now that we know the group name to use – all the other information we need to build up our authority granting command is available in the error message. Here is a table of the information we found and where we found it.

Required Info	Value	Source of Value
Entity Type	Group	Best practice decision
Entity	mqgemadm	Looking up reported users group membership
Object Type	Queue Manager	Error message title line “[qmgr]”
Object Name	MQG2	Error message title line “… object MQG2 …”
Authority required	connect	Error message EXPLANATION section

From this table we can build up an MQSC command to grant the missing authority. We either issue this command from a privileged user Id, or add it to our queue manager start-up script. I suggest doing the former as there are going to several of these commands needed. Once you’ve completed the exercise it might be appropriate to gather up the commands that were needed for future use to put into such a script.

You’ll notice that there is no need to mention the object name in the following command because it’s the queue manager object and there is only one. Some people add it in and some use OBJNAME(SELF) but it can simply be omitted.

SET AUTHREC OBJTYPE(QMGR) GROUP('mqgemadm') AUTHADD(CONNECT)

So now, we run the application again, and it fails again, with the same reason code. Nothing has changed!

Well actually something has changed. If you look in the AMQERR01.LOG file for the latest error it looks like this.

AMQ8245W: Entity 'mqgusr1' has insufficient authority to display object MQG2 [qmgr].

EXPLANATION:
The specified entity is not authorized to display the required object. The following requested permissions are unauthorized: dsp

So, something has changed. Rather than reporting that we don’t have connect authority it is now reporting that we don’t have display (dsp) authority. As before we can build up an MQSC command to grant the missing authority.

SET AUTHREC OBJTYPE(QMGR) GROUP('mqgemadm') AUTHADD(DSP)

So now, once more, we run the application again, and it fails again, with the same reason code again. However, we’re familiar with this now. It’s not the same issue, just the same reason code. So, again, we look in the AMQERR01.LOG file for the latest error. In my example, the next error looks like this.

AMQ8077W: Entity 'mqgusr1' has insufficient authority to access object SYSTEM.ADMIN.COMMAND.QUEUE [queue].

EXPLANATION:
The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: put

Let’s build up a table of our pieces of information like we did earlier.

Required Info	Value	Source of Value
Entity Type	Group	Best practice decision
Entity	mqgemadm	Looking up reported users group membership
Object Type	Queue	Error message title line “[queue]”
Object Name	SYSTEM.ADMIN.COMMAND.QUEUE	Error message title line just before “[queue]”
Authority required	put	Error message EXPLANATION section

As before, we can use this information to build up an MQSC command to grant the missing authority. Now we also have an object name, so this command will look slightly longer than the previous ones you saw.

SET AUTHREC PROFILE(SYSTEM.ADMIN.COMMAND.QUEUE) OBJTYPE(QUEUE) GROUP('mqgemadm') AUTHADD(PUT)

I hope that is enough of an example to illustrate the technique. Just keep viewing the AMQERR01.LOG and finding the reported missing authority and fixing it with the appropriate MQSC AUTHREC command (or the equivalent setmqaut command if you prefer). Look at the error messages closely as all the information you need is in there.

Logging Client Connections

A recent discussion about logging of client connections, both those that are blocked and those that succeed, got me thinking that you can capture all the data you need to create such a log with a combination of MQ Event messages and MQ Accounting records (on distributed queue managers). This means you can do this with MQEV. We’ve written about writing log files with the MQSCX control language before, but I thought it would be good to have an MQEV example of this too.

CHLAUTH blocking connections

The IBM MQ Queue manager emits an event message whenever it denies access to a channel connection as a result of matching a blocking CHLAUTH rule. This event message contains a number of very useful pieces of information to identify the channel that was blocked. In the case of a client channel connection these are:-

Field Description	MQ PCF Identifier	MQEV script response variable
Channel Name	MQCACH_CHANNEL_NAME	event.CHANNEL
Connection Name	MQCACH_CONNECTION_NAME	event.CONNAME
SSL Peer Name	MQCACH_SSL_PEER_NAME	event.SSLPEER
SSL Issuer Name	MQCA_SSL_CERT_ISSUER_NAME	event.SSLCERTI
Client User Identifier	MQCACH_CLIENT_USER_ID	event.CLNTUSER
Application Type	MQIA_APPL_TYPE	event.APPLTYPE
Application Name	MQCACF_APPL_NAME	event.APPLNAME

Accounting data recording all connections

If you enable accounting data collection, especially ACCTMQI, an accounting record is emitted by the queue manager each time a successful connection disconnects, and also periodically if connections are longer lived than the accounting interval. This record contains a number of very useful pieces of information to identify the application that connected. In the case of a client application these are:-

Field Description	MQ PCF Identifier	MQEV script response variable
Application Name	MQCACF_APPL_NAME	data.ACCTMQI
User Identifier	MQCACF_USER_IDENTIFIER	data.USERID
Connection Name	MQCACH_CONNECTION_NAME	data.CONNAME
Channel Name	MQCACH_CHANNEL_NAME	data.CHANNEL
Remote Product	MQCACH_REMOTE_PRODUCT	data.RPRODUCT
Remote Version	MQCACH_REMOTE_VERSION	data.RCVERSION

With CHLAUTH and ACCTMQI enabled, you can direct MQEV to collect these emitted records and write the data out to a log file with the format of your choosing.

CONNECT 22:50:53 Channel: MQGEM.SVRCONN from '127.0.0.1' for Application: ':\mqm9300\bin64\amqsputc.exe'
CONNECT 22:54:57 Channel: MQGEM.SVRCONN from '127.0.0.1' for Application: ':\mqm9300\bin64\amqsputc.exe'
BLOCKED 22:55:01 Channel: MQGEM.SVRCONN.TLS from 'GEMWIN10 (127.0.0.1)' for Application: 'MQGem Software MO71'

client_log_2023_05_25.txt

In our example we create a new log file every day by creating the file name using the built-in date formatting function, and then each line we write in the file has a timestamp. This version of the function creates a line in the file suitable for a human to read, but also with eye-catching strings at the start of each line that could be used to sort the file (see example above). An alternative could be to write a CSV file instead of a text file and make the output a comma-separated format instead of just a text string and then you could import it into a spreadsheet later.

Here is an example of how that could look in your mqev.mqx script. First we show you the small function to write out the line to the file.

*********************************************************************
* Function to log client channel connections (failed or successful)
* Allow = 0 - blocked
* Allow = 1 - warning of blocked, thus allowed
* Allow = 2 - connection made
*********************************************************************
func logClient(ChlName, IPAddr, ApplName, Allow, Time)
  @filename = "C:\logs\client_log_" + date(_time, "y_mm_d") + ".txt"

  * Open the logging file in append mode
  @hf = fopen(@filename, "a")
  if (@hf = -1)
    print "Error opening", @filename, "ErroNo=", _errno, _errnostr
    return
  endif

  * Build up the string to write to the logging file
  @logtime    = date(Time, "H:M:S")
  @chldetails = "Channel: " + @ChlName + " from '" + @IPAddr +
              + "' for Application: '" + @ApplName + "'"
  if (@Allow = 2)
    fprint @hf, "CONNECT", @logtime, @chldetails
  endif
  if (@Allow = 1)
    fprint @hf, "WARNING", @logtime, @chldetails
  endif
  if (@Allow = 0)
    fprint @hf, "BLOCKED", @logtime, @chldetails
  endif

  fclose(@hf)
endfunc

Having written our logging function, we can call this whenever we catch an appropriate event message, passing in the time the event happened as the time that should be written in the log file:

*********************************************************************
* Function for processing an event                                  *
*********************************************************************
func MQEVEvent()
  if (event.EVTYPE = CHANNEL)
    ************************************
    * Really blocked the connection    *
    ************************************
    if(event.EVREASON = CHLBLKNOAC OR +
       event.EVREASON = CHLBLKADDR OR +
       event.EVREASON = CHLBLKUSER)
      @Allow = 0
    endif
    ************************************
    * Just warned about the connection *
    ************************************
    if(event.EVREASON = CHLBLKWNOAC OR +
       event.EVREASON = CHLBLKWADDR OR +
       event.EVREASON = CHLBLKWUSER)
      @Allow = 1
    endif
    ************************************
    * Only looking for client channels *
    ************************************
    if (event.CLNTUSER != ' ')
      logClient(event.CHANNEL, event.CONNAME, event.APPLNAME, +
                @Allow, event.EVTIME)
    endif
  endif
endfunc

And we can also call this whenever we catch an appropriate accounting record, weeding out the MCA channels (application names of runmqchl and amqrmppa, and only logging it on the first record (data.SEQNUM = 0) for a long-lived connection, and passing in the connection time (rather than the time the accounting record was created which is much later) as the time that should be written in the log file:

*********************************************************************
* Function for processing an Accounting MQI message                 *
*********************************************************************
func MQEVAcctMQI()
  if (data.CHANNEL AND +
      findstri(data.ACCTMQI, "runmqchl") = 0 AND +
      findstri(data.ACCTMQI, "amqrmmpa") = 0 AND +
      data.SEQNUM = 0)
    logClient(data.CHANNEL, data.CONNAME, data.ACCTMQI, 2, +
              data.CONNTI)
  endif
endfunc

There is, of course, lots more you could do with this. The format of the output file is entirely up to you. If there are other things which are important to log, you can add those. The data available in each type of record that the queue manager emits is shown in the tables at the beginning of the post.

This example has specifically focused on logging client connections, but you could extend this to MCA channels as well by removing the code that ensures only client connections are being dealt with.

You could choose to keep or throw away the event messages and accounting records that you have used to create the file with. An example of discarding an accounting record after you have used it for what you needed is shown in this post.

If you keep the data you can come back to it later and create other files based on DISPLAY command output from MQEV, just as you can with DISPLAY command output from IBM MQ as discussed in this blog post.

---

Read more about MQEV, and download a copy, from the MQEV Web Page. If you don’t have a licence and would like to try out MQEV before deciding whether to buy then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

MQEdit version 9.3.1 is released

MQGem Software is pleased to announce that a new version of MQEdit, our Live Parsing Editor for IBM MQ messages, is now available.

The main features of the release are as follows:-

• Have MQEdit prompt you for your KDB password
  This feature was initially added in MO71 and we have now also added the same to MQEdit. All the details can be found at the aforementioned link.
• More flexible Message Context Settings
  The are many different actions you may take on an MQ message using MQEdit; moving, copying, small corrections, big edits, and creating brand new messages from scratch.

  Each of these different actions may well want to use a different message context. For example, when moving a message, you likely want to use “Pass All Context” whereas when creating a new message from scratch “Default Context” might be most appropriate. If making a small correction to an existing message you might need to use “Set All Context” depending on what you need to correct.

  Earlier versions of MQEdit had a menu option to allow you to choose which message context setting you wanted to use but the default was built into MQEdit.

  This release adds a number of improvements.

  1. You can now set your own default value for message context in the preferences dialog. In fact two defaults, one for when you are adding a new message, where MQEdit starts with the value set to “Default Context” but you can change it. The other is for operations when you are updating a message, e.g. editing it on the same queue or moving it to another queue. In this case MQEdit starts with the value set to “Pass All Context” but you can change it.
  2. Having the ability to set your own defaults may mean you rarely, if ever, need to change the message context in use, but if you do, you can choose whether MQEdit keeps the setting you choose in the menu for all future messages, or whether it is a one-off change just for this message, and after you’re done with the message, the option reverts to your default that you set in the preferences dialog.
  3. Finally, the menu option that existed in prior versions of MQEdit is enhanced to have a different sub-menu for Add actions and Update actions. This submenu also shows you what the current value is, especially useful if you have the previous feature in use.

---

The new version can be downloaded from the MQEdit Download Page. Any current licensed users of MQEdit can run the new version on their existing licence. If you don’t have a licence and would like to try out MQEdit then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Managing Not Authorized (Type 4) Events

There are various types of IBM MQ Not Authorized events:

• Not Authorized (type 1) MQCONN not authorized
• Not Authorized (type 2) MQOPEN/MQPUT1 not authorized
• Not Authorized (type 3) MQCLOSE not authorized
• Not Authorized (type 4) Command not authorized
• Not Authorized (type 5) MQSUB not authorized
• Not Authorized (type 6) MQSUB Destination not authorized

This post is focusing on the Type 4 events which report when a command, e.g. MQSC or PCF, is issued and fails because it is not authorized. When a user that does not have authority to display all the queues on a queue manager issues a command such as:-

DISPLAY QLOCAL(*) ALL

then you might end up with rather a lot of these event messages, one written for each queue that the user does not have display access to.

Unfortunately these event messages tell you very little. Their entire content is documented in IBM Docs as follows:-

Event data

QMgrName

Description:	Name of the queue manager generating the event.
Identifier:	MQCA_Q_MGR_NAME.
Data type:	MQCFST.
Maximum length:	MQ_Q_MGR_NAME_LENGTH.
Returned:	Always.

ReasonQualifier

Description:	Identifier for type 4 authority events.
Identifier:	MQIACF_REASON_QUALIFIER.
Data type:	MQCFIN.
Values:	MQRQ_CMD_NOT_AUTHORIZED Command not authorized.
Returned:	Always.

Command

Description:	Command identifier. See the MQCFH header structure, described in Event message MQCFH (PCF header).
Identifier:	MQIACF_COMMAND.
Data type:	MQCFIN.
Returned:	Always.

UserIdentifier

Description:	User identifier that caused the authorization check.
Identifier:	MQCACF_USER_IDENTIFIER.
Data type:	MQCFST.
Maximum length:	MQ_USER_ID_LENGTH.
Returned:	Always.

One thing that is missing from these events is the object name the event is about. If you issue a generic display command you can get hundreds of identical events because there is nothing to tell you which event is for which object. Unfortunately there is also nothing to tell you that this was as a result of a generic display command either, just that it was a display command. You can infer that it was a generic display command because you get so many identical events from the same user id in a very short space of time.

It is really a shame that these actions even generate such events at all. The user asked to see all the objects they were allowed to see, and they were only given command responses for those objects they were allowed to see. Raising authority events for such an action doesn’t really seem warranted. Perhaps we should raise an IDEA with IBM to suggest this could be turned off.

Saving off these events to a different Event Stream

Another blog post covers how you can save off different MQ event messages to different streams in order to apply longer (or shorter) retention intervals to them, and these specific event messages do seem like an excellent candidate for that, this time though in order to have a much shorter retention interval.

As noted in that blog post, you might normally like to retain security related events for longer than the MQEV default of 90 days, but for these we might like a much shorter interval.

DEFINE EVSTREAM(SECURITY) TYPE(EVENTS) RETINTVL(120)
DEFINE EVSTREAM(DISCMDSEC) TYPE(EVENTS) RETINTVL(7)

Then the mqev.mqx script would be enhanced to include the following:-

*********************************************************************
* Function for processing an event                                  *
*********************************************************************
func MQEVEvent()
  if (event.EVTYPE = AUTHOR)
    if (event.EVREASON = AUTCMD AND +
        substr(event.SUMMARY,1,27) = "Command not Auth - Inquire ")
        _stream = "DISCMDSEC"
    else
      _stream = "SECURITY"
    endif
  endif
endfunc

While we could have checked the event.COMMAND attribute in the event against const.MQCMD_INQUIRE_Q and all the other MQCMD_* constants, that would have been a very long list and we’d have to maintain it too. Instead we use the event.SUMMARY string which will always begin with the same characters for an Inquire command and let the MQGem team keep MQEV up-to-date with any new commands that are added to IBM MQ.

Now that all these commands are being stored on a different stream we can view our other events without these in the way. We can also easily purge this stream and throw away these events whenever we want to, and MQEV will automatically throw them away for us after the retention interval on the stream expires.

Alternatively, if you just want to immediately throw away ALL of these DISPLAY events (whether from generic display commands or specific display commands) you could instead set the stream to null like this:-

_stream = "$null"

Event Storms

Another thing that MQEV does to assist you not being completely flooded by events such as this, is that it detects events that are identical. This is known as an event storm. These “Command Not Authorized” events fall squarely in this category since there isn’t even an object name in the event message.

By default, if MQEV sees more than 20 identical events in a 60 second time period, then it will begin to capture them as a repeated event. This means you will see 20 identical events, and then at the end of the 60 seconds, one more event with an EVREPEAT count showing how many more there were.

DISPLAY EVENTS(*) WHERE(EVREPEAT) ALL

EVQMGR(MQG1)        EVENTS(DISCMDSEC)   EVTIME(2022-08-18 17:38:44 (Local))      
EVREASON(AUTCMD)    EVTYPE(AUTHOR)      EVUSERID(mqgusr1)   EVOBJTYPE(CHANNEL)   
COMMAND(Inquire Channel)                EVENTID(00000068)   CFHCMD(44)           
CFHREASON(2035)     SUMMARY(Command not Auth - Inquire Channel - Channel:)       
RSNQUAL(4)          USERID(mqgusr1)     EVREPEAT(15)                             
_________________________________________________________________________________
EVQMGR(MQG1)        EVENTS(DISCMDSEC)   EVTIME(2022-08-18 17:38:37 (Local))      
EVREASON(AUTCMD)    EVTYPE(AUTHOR)      EVUSERID(mqgusr1)   EVOBJTYPE(QUEUE)     
COMMAND(Inquire Q)  EVENTID(00000067)   CFHCMD(44)          CFHREASON(2035)      
SUMMARY(Command not Auth - Inquire Q - Queue:)              RSNQUAL(4)           
USERID(mqgusr1)     EVREPEAT(113)                                                
_________________________________________________________________________________

You can alter these settings using an ALTER EV STORMTHR(number) STORMINT(seconds) command.

---

Drowning in MQ events? Let MQEV help.

---

Read more about MQEV, and download a copy, from the MQEV Web Page. If you don’t have a licence and would like to try out MQEV before deciding whether to buy then send an email to support@mqgem.com and a 1-month trial licence will be sent to you.

Error message AMQ9557 with CONNAUTH

This question still comes up a lot so I thought it might be worth writing this up.

You’ve received an error message like the following:-

AMQ9557: Queue Manager User ID initialization failed for 'mqgemusr'.

EXPLANATION:
The call to initialize the User ID 'mqgemusr' failed with CompCode 2 and Reason 2035.
If an MQCSP block was used, the User ID in the MQCSP block was 'hughson'.
ACTION:
Correct the error and try again.

You recognise both the user IDs mentioned in the error message. ‘mqgemusr’ is your client machine’s logged on user id. It shouldn’t be being used. You supplied a user ID (‘hughson’) with its password and had expected that this would be the user id that would be used.

A common reason for this particular issue is due to the default value in the Connection Authentication (CONNAUTH) settings. In IBM MQ V8, the ADOPTCTX attribute had a default value of NO, and later in IBM MQ V9.0.4 this was changed to YES.

What is the ADOPTCTX attribute for? This attribute is how you tell the queue manager whether you want the application connection to run with the user ID that it has provided for password validation for all it’s subsequent authorization checks, and to ignore the client machine’s logged on user id.

To check whether you are suffering from this problem, first issue this command to discover the name of the AUTHINFO object that is in used to configuration your Connection Authentication settings.

DISPLAY QMGR CONNAUTH

The use the name that was returned in the CONNAUTH attribute to issue this command.

DISPLAY AUTHINFO(name-from-above) ALL

You will get output something like this, depending on your IBM MQ version of course.

AMQ8566I: Display authentication information details.
   AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
   AUTHTYPE(IDPWOS)                        ADOPTCTX(NO)
   DESCR( )                                CHCKCLNT(OPTIONAL)
   CHCKLOCL(OPTIONAL)                      FAILDLAY(1)
   AUTHENMD(OS)                            ALTDATE(2021-07-06)
   ALTTIME(16.43.40)

Check the value in the ADOPTCTX attribute. In order to ensure that the password validated user id is the one that is used for your authorization checks, make sure it has the value of YES.

ALTER AUTHINFO(name-from-above) AUTHTYPE(IDPWOS) ADOPTCTX(YES)

Remember that a change to Connection Authentication settings requires a refresh to be picked up.

REFRESH SECURITY TYPE(CONNAUTH)

IBM MQ New Year’s Resolutions

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.

MO71 version 9.0.0 is released

MQGem Software is pleased to announce that a new version of MO71, our GUI Administrative tool for IBM MQ, is now available.

The main features of the release are as follows:-

Support for MQ Command Level 900

As normal with a new release of IBM MQ, there is a new command level. MO71 now supports this new command level and its contents.

Work with Advanced Message Security (AMS) Protection Policies

You can now define, update and delete AMS Protection Policies. Other aspects of MO71 have also been updated accordingly to deal with these policies, for example updates to Default Lists and Usage Tailoring. Read more about this feature in MO71 – AMS Policy Commands.

Support of CCDT URL

MQ V9 allows a connecting application to specify the URL location of the CCDT file to use. This field can be specified in the location dialog. Read more about this feature in Using the CCDT URL

Add monitor times to your main window display

Show last monitor time on main window

If you wish you can display the last time (or elapsed time) that a response was received from a Queue Manager that is monitored.

Changing multiple objects can now belong to different Queue Managers

If multiple objects are selected from a list and those objects belong to different Queue Managers then the resulting dialog will qualify each object with their owning Queue Manager. It is now possible, for example, to change the maximum depth of multiple queues on multiple Queue Managers with a single click. Or alternatively you can stop/start multiple channels on different Queue Managers with a single press of a button. Read more about this feature in Changing multiple objects at once.

Changing multiple objects is reflected in the dialog title bar

The text [Multiple Objects] will be shown in the title bar in this case.

Exporting lists now has a new ‘All Fields’ checkbox

Quick way to export all fields

Previously, when exporting from a list of objects, only the fields which were actually in the list would be exported. This is useful for certain types of displays, such as text and CSV. However, for MQSC this can mean that you would get an incomplete object definition. A new ‘All fields’ checkbox now allows you to request that all the object fields are exported.

New Buffer Pool and Page Set dialogs displayable

MO71 now supports the display of z/OS Buffer Pool and Page Set objects. Read more about this feature in View Buffer Pool and Pageset Usage via MO71.

---

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 support@mqgem.com and a 1-month trial licence will be sent to you.

NEW MQSCX Example Script

Sometimes the best way to learn to use a new program, is to see examples.

If you’re new to MQSCX, you may find our example scripts very useful as a basis for creating your own. You can get the Example Scripts download from the MQSCX Download page on our website.

We’ve just added a new script to the package, one donated by a customer. This script is called mqauthlist.mqx and its purpose is to create a report (written to a file) that shows the current authorization settings for one or more IBM MQ Queue Managers.

Here are some example lines from the report it generates.

MQ Authorization Report for MQG1 on January 8th, 2016

**---------------------------------------------------------------**
** Queue Manager MQG1                                            **
**---------------------------------------------------------------**

** PRINCIPAL - morag@MQGEM1
Object Authorizations:
QUEUE    : @CLASS                  - CRT
QUEUE    : BUSINESS.CLASS          - BROWSE,GET,INQ,PUT
QUEUE    : CHECK.IN                - BROWSE,GET,INQ,PUT
QUEUE    : ECONOMY.CLASS           - BROWSE,GET,INQ,PUT
QUEUE    : MQGEM101.CLIENT.Q       - BROWSE,CHG,CLR,DLT,DSP,GET,PUT
CHANNEL  : @CLASS                  - CRT
CHANNEL  : MQGEM.SVRCONN           - CHG,DLT,DSP,CTRL,CTRLX
CHANNEL  : TO.MQG1.MQGEM101        - CHG,DLT,DSP,CTRL,CTRLX
LISTENER : @CLASS                  - CRT
LISTENER : TCP.LSTR                - CHG,DLT,DSP,CTRL

As well as being a very useful script in its purpose, it is also an excellent demonstration of some of new features recently added in a refresh of MQSCX. A few more posts will be written to illustrate these new features, using this new script as an example, so watch out for those.

• MQSCX feature – String Replace
• Novel use of sorting
• MQSCX feature – write to a file
• Novel use of MQSCX foritem
• MQSCX feature – CommandLevel and Platform
• MQSCX feature – Machine O/S

---

The best way to understand scripts is of course to try them out yourself. If you are not currently an MQSCX licence holder, you may email support@mqgem.com to request a trial licence.

WebSphere Integration User Group (UK)

Tuesday 14th July was the WebSphere Integration User Group (UK) annual event hosted in IBM Hursley.

Lovely venue at @IBM Hursley for today's Websphere Integration User Group UK event #wiuguk

— Pete van't H (@TheSneakyP) July 14, 2015

Welcoming lots of people (including a few familiar faces!) into the #IBMHursleyEBC for the #WIUGUK event

— Hursley EBC (@HursleyEBC) July 14, 2015

After the opening keynote, the break-out sessions split up into five tracks, Integration; Messaging; Cloud / API Management; Business Process Management; and Architecture & Related topics. I was there for the Messaging track.

We started in the Auditorium for the Keynote “2-Speed IT” by Andy Humphreys, a Cross Portfolio Product Manager at the IBM Hursley Laboratory. One strong message was that we’re still going to need lots of integration.

https://twitter.com/IBMSystemsUKI/status/620982359303716864

After the keynote we split into the five tracks, and first up on the Messaging track was “What’s new in IBM Messaging” presented by Mark Taylor. This presentation included the new features added in IBM MQ V8 FixPack 3 which was recently released, including the new 802 command level – which I recently updated my “What’s in Command Level 801” blog post to include; the deprecation of more weak CipherSpecs (read more in Deprecated CipherSpecs); PAM based Authorisation; and extensions to the Channel Exit Parameters structure to provide exits with RVERSION and RPRODUCT (very handy fields that I recently described in “IBM MQ Little Gem #2: RPRODUCT and RVERSION”). As a result of this presentation I have been able to update my earlier blog post about FixPack 8.0.0.3 to be more complete.

At #WIUGUK @marketaylor02 tells us What's New in IBM #Messaging - #IBMMQ #MQAppliance pic.twitter.com/zAf3SU8QNe

— Morag Hughson (@MoragHughson) July 14, 2015

After lunch in the central hall of Hursley House, and chatting to a number of people I hadn’t seen in a while, it was back to the sessions. Matt Whitehead kicked things off after lunch with “MQ Light and IBM MQ”.

After lunch at #WIUGUK Matthew Whitehead gives us an update on #IBMMQ #MQLight pic.twitter.com/QpHqgmzwLh

— Morag Hughson (@MoragHughson) July 14, 2015

After a very short break, next up in the same room was “IBM MQ and Security” by Mark Taylor. This was an overview of all the security features in IBM MQ, including details on those added in V8 at GA, and the features that were released later in Fix Packs 2 and 3.

Another great session at #WIUGUK, this time on #IBMMQ #security by @marketaylor02

— Morag Hughson (@MoragHughson) July 14, 2015

After coffee and cake in the Central Hall, the last breakout session of the day was about the “MQ Appliance” with Anthony Beardsmore. This session was very interactive with lots of discussion in the room about the Appliance.

Last breakout session of the day at #WIUGUK is @antbeardsmore telling us about the #IBMMQ #MQAppliance pic.twitter.com/ajSw9sD9Pc

— Morag Hughson (@MoragHughson) July 14, 2015

Links to the presentation material that is embedded above are also available on the WebSphere Integration User Group webpage.

The day finished off back in the Auditorium with a brief “Ask the Experts Panel” session before it was time to head home.

It was a great event, and I’d like to thank the organisers who I know work very hard to arrange this event, including lots of their own personal time. You guys rock!

Previous years events:-

• WebSphere Integration User Group – 1st July 2014

---

Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on:    

Deprecated CipherSpecs

Earlier in Blog Post: Know your protocol I wrote about how IBM MQ V8 FixPack 2 had deprecated all the SSL 3.0 CipherSpecs and turned them off by default.

Now in FixPack 3 a further set of CipherSpecs have been deprecated so that, by default, attempts to use them will result in a error. The additional CipherSpecs deprecated in FixPack 3 are those which use no encryption; the RC algorithms (RC2 and RC4); and single DES.

UPDATE: Now with APAR IV90867, which is targeted for IBM MQ V8 FixPack 6, a further set of CipherSpecs have been deprecated. The additional CipherSpecs deprecated in FixPack 6 are those which use the Triple DES algorithm.

UPDATE: Now with V9.1, a further two CipherSpecs have been deprecated. The additional CipherSpecs deprecated in V9.1 are those which use the TLS 1.0 protocol.

Whatever version of MQ you are currently using, you should consider this as a strong hint to look at your use of any of these CipherSpecs and change to a stronger one where possible.

CipherSpecs now deprecated in IBM MQ, highlighted column shows the reason for deprecation.

CipherSpec Name	Protocol Used	Data Integrity	Encryption		Added in	Deprecated in
			Algorithm	Bits
AES_SHA_US	SSL 3.0	SHA-1	AES	128	V5.3
DES_SHA_EXPORT	SSL 3.0	SHA-1	DES	56	V5.3
DES_SHA_EXPORT1024	SSL 3.0	SHA-1	DES	56	V5.3
FIPS_WITH_DES_CBC_SHA	SSL 3.0	SHA-1	DES	56	V6
FIPS_WITH_3DES_EDE_CBC_SHA	SSL 3.0	SHA-1	3DES	168	V6
NULL_MD5	SSL 3.0	MD5	None	0	V5.3
NULL_SHA	SSL 3.0	SHA-1	None	0	V5.3
RC2_MD5_EXPORT	SSL 3.0	MD5	RC2	40	V5.3
RC4_MD5_EXPORT	SSL 3.0	MD5	RC4	40	V5.3
RC4_MD5_US	SSL 3.0	MD5	RC4	128	V5.3
RC4_SHA_US	SSL 3.0	SHA-1	RC4	128	V5.3
RC4_56_SHA_EXPORT1024	SSL 3.0	SHA-1	RC4	56	V5.3
TRIPLE_DES_SHA_US	SSL 3.0	SHA-1	3DES	168	V5.3
TLS_RSA_EXPORT_WITH_RC2_40_MD5	TLS 1.0	MD5	RC2	40	?
TLS_RSA_EXPORT_WITH_RC4_40_MD5	TLS 1.0	MD5	RC4	40	?
TLS_RSA_WITH_DES_CBC_SHA	TLS 1.0	SHA-1	DES	56	V6
TLS_RSA_WITH_NULL_MD5	TLS 1.0	MD5	None	0	?
TLS_RSA_WITH_NULL_SHA	TLS 1.0	SHA-1	None	0	?
TLS_RSA_WITH_RC4_128_MD5	TLS 1.0	MD5	RC4	128	?
ECDHE_ECDSA_NULL_SHA256	TLS 1.2	SHA-1	None	0	V7.1
ECDHE_ECDSA_RC4_128_SHA256	TLS 1.2	SHA-1	RC4	128	V7.1
ECDHE_RSA_NULL_SHA256	TLS 1.2	SHA-1	None	0	V71.
ECDHE_RSA_RC4_128_SHA256	TLS 1.2	SHA-1	RC4	128	V7.1
TLS_RSA_WITH_NULL_NULL	TLS 1.2	None	None	0	?
TLS_RSA_WITH_NULL_SHA256	TLS 1.2	SHA-256	None	0	V7.0.1
TLS_RSA_WITH_RC4_128_SHA256	TLS 1.2	SHA-1	RC4	128	?
TLS_RSA_WITH_3DES_EDE_CBC_SHA	TLS 1.0	SHA-1	3DES	168	V6
ECDHE_ECDSA_3DES_EDE_CBC_SHA256	TLS 1.2	SHA-1	3DES	168	V7.1
ECDHE_RSA_3DES_EDE_CBC_SHA256	TLS 1.2	SHA-1	3DES	168	V7.1
TLS_RSA_WITH_AES_128_CBC_SHA	TLS 1.0	SHA-1	AES	128	V6
TLS_RSA_WITH_AES_256_CBC_SHA	TLS 1.0	SHA-1	AES	256	V6

As an alternate way of thinking about it, you should be choosing a CipherSpec from the 17 listed in the following table, or moving to use the ANY* Alias CipherSpecs.

CipherSpecs still supported in IBM MQ. All of the TLS 1.2 entries are FIPS 140-2 certified, none of the TLS 1.3 entries are though.

Platform	CipherSpec Name	Protocol Used	Data Integrity	Encryption		Suite B	Added in
				Algorithm	Bits
LUW	TLS_AES_128_GCM_SHA256	TLS 1.3	GCM	AES-128 with GCM	128	No	V9.1.4
LUW	TLS_AES_256_GCM_SHA384	TLS 1.3	GCM	AES-256 with GCM	256	No	V9.1.4
LUW	TLS_CHACHA20_POLY1305_SHA256	TLS 1.3	POLY1305	CHACHA20	256	No	V9.1.4
LUW	TLS_AES_128_CCM_SHA256	TLS 1.3	CBC-MAC	AES-128 with CTR	128	No	V9.1.4
LUW	TLS_AES_128_CCM_8_SHA256	TLS 1.3	CBC-MAC	AES-128 with CTR	128	No	V9.1.4
All	TLS_RSA_WITH_AES_128_CBC_SHA256	TLS 1.2	SHA-256	AES	128	No	V7
All	TLS_RSA_WITH_AES_256_CBC_SHA256	TLS 1.2	SHA-256	AES	256	No	V7
All	TLS_RSA_WITH_AES_128_GCM_SHA256	TLS 1.2	AEAD AES-128 GCM	AES	128	No	V7.1
All	TLS_RSA_WITH_AES_256_GCM_SHA384	TLS 1.2	AEAD AES-128 GCM	AES	256	No	V7.1
All	ECDHE_ECDSA_AES_128_CBC_SHA256	TLS 1.2	SHA-256	AES	128	No	V7.1
All	ECDHE_ECDSA_AES_256_CBC_SHA384	TLS 1.2	SHA-384	AES	256	No	V7.1
LUW	ECDHE_ECDSA_AES_128_GCM_SHA256	TLS 1.2	AEAD AES-128 GCM	AES	128	128 bit	V7.1
LUW	ECDHE_ECDSA_AES_256_GCM_SHA384	TLS 1.2	AEAD AES-128 GCM	AES	256	192 bit	V7.1
All	ECDHE_RSA_AES_128_CBC_SHA256	TLS 1.2	SHA-256	AES	128	No	V7.1
All	ECDHE_RSA_AES_256_CBC_SHA384	TLS 1.2	SHA-384	AES	256	No	V7.1
All	ECDHE_RSA_AES_128_GCM_SHA256	TLS 1.2	AEAD AES-128 GCM	AES	128	No	V7.1
All	ECDHE_RSA_AES_256_GCM_SHA384	TLS 1.2	AEAD AES-128 GCM	AES	256	No	V7.1

The table in Knowledge Center: Specifying CipherSpecs only shows the supported CipherSpecs and there is a separate page for the list of Deprecated CipherSpecs.

Re-enabling the deprecated CipherSpecs

Be aware that if you have re-enabled SSL V3.0 CipherSpecs at IBM MQ V8 FixPack 2, and you upgrade to FixPack 3, you will have further re-enabling to do. It is not sufficient simply to re-enable the SSL V3.0 protocol as you did with FixPack 2, you also have to specify the weak CipherSpec you wish to allow use of.

If the CipherSpec you wish to re-enable is an SSL V3.0 CipherSpec one step you will need to do is re-enable the protocol. As detailed in Know your protocol this is done by editing the qm.ini file:-

SSL:

AllowSSLV3=Y

or setting the AMQ_SSL_V3_ENABLE=1 environment variable.

Additionally, to re-enable the specific CipherSpec, you can edit the qm.ini file to provide the name of the CipherSpec you wish to allow to be used:-

SSL:

AllowWeakCipherSpec=TRIPLE_DES_SHA_US

or set the AMQ_SSL_WEAK_CIPHER_ENABLE=TRIPLE_DES_SHA_US environment variable.

This setting can be a list of CipherSpecs, or ‘All’ to turn them all back on.

Without these settings use of a weak CipherSpec at define-time will result in:-

AMQ8242: SSLCIPH definition wrong.

and at run-time will result in an error message thus:-

-------------------------------------------------------------------------------
20/07/2015 17:42:26 - Process(6040.1) User(MUSR_MQADMIN3) Program(runmqchl.exe)
                      Host(GEM45) Installation(800FP3)
                      VRMF(8.0.0.3) QMgr(QM1)
                     
AMQ9674: The channel 'QM1.TO.QM2.SSL01' specified a weak or broken CipherSpec.

EXPLANATION:
The SSL or TLS channel 'QM1.TO.QM2.SSL01' is configured to use a weak or broken
CipherSpec 'TRIPLE_DES_SHA_US'. 

This error occurs when the channel has requested to use a CipherSpec that
utilizes cryptographic algorithms or protocols that are now considered to be
broken or weak. 

The channel did not start.
ACTION:
Ensure that the channel is configured to use a CipherSpec that uses a stronger
set of cryptographic algorithms or a stronger protocol. 

Alternatively, configure the queue manager to re-enable the weaker CipherSpec
'TRIPLE_DES_SHA_US' using the AMQ_SSL_WEAK_CIPHER_ENABLE environment variable,
or via the 'AllowWeakCipherSpec' attribute under the SSL stanza in the qm.ini
file. 
-------------------------------------------------------------------------------

Hopefully you won’t ever need to re-enable these old, weak CipherSpecs, but there’s always the chance that you have a channel that talks to an old version queue manager, and you’ll need one of these weaker CipherSpecs for that purpose. At least with this new re-enablement method you’ll only be allowing the one you need to be used, instead of opening them all up.

IBM resources on the same subject:-

• CipherSpec values supported in IBM MQ
• Deprecation: weaker cryptographic algorithms
• Specifying CipherSpecs
• SSL and TLS Cipher Specification Deprecations for the MQ Product

Other resources on the same subject:-

• Weak or broken cipher spec’s are blocked – PTF UI29471 – MQ V8.0

---

Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on: