RESLEVEL profile and channels

I recently gave a presentation, “Securing your z/OS queue manager” at the GSE Nordic Region Conference and there was one subject that was not covered in my presentation that really should have been, and that was the RESLEVEL profile. So this blog post has been written to supplement that presentation and describe what the RESLEVEL profile is, and also more specifically, how it interacts with the user ids used by IBM MQ channels.


There is one RESLEVEL profile for each z/OS queue manager[1], hlq.RESLEVEL, whose job it is to determine which user id(s) to use when making authority checks. Access checks are made whenever an application wants to use a resource, for example it does an MQOPEN of a queue for the purpose of putting messages to it. Applications which use an IBM MQ queue manager on z/OS can run in a number of different environments and each environment has some different ways of assigning user ids to the application.

RESLEVEL profile

The RESLEVEL profile is how the queue manager determines how many user IDs to make authority checks on

The simplest environment is batch, where the user ID that is running the job is the only user ID available to use for authority checks. However, in CICS and IMS environments, there is both a user ID for the hosting region and also a user ID representing the hosted application. Use of the RESLEVEL profile can allow you to choose to use one or both of these user ids for authority checks. For the CHINIT environment which covers MCA channels and MQI channels, there is also a choice of several user ids which will be discussed a little later.

The RESLEVEL profile is used differently than other profiles that you define to protect IBM  MQ resources. Normally the queue manager would ask the External Security Manager (ESM) whether a user id has, say ALTER access, to a particular profile. For RESLEVEL though, the queue manager asks the ESM to tell it what access level the user ID owning the region in question has on the profile. The answer that is returned determines how many user ids will be used for authority checks in this environment.

This table is a combination of the various environment tables (which can be found in the child pages of The RESLEVEL security profile in Knowledge Center) and shows what is decided as a result of each of the possible answers. It shows that all the environments follow a very similar pattern. You can see that with a high level of access granted to this profile, security checking for an entire region can be turned off. So be especially careful with this profile, and also make sure there are no highly generic profiles in the MQADMIN class[2], e.g. hlq.**.

access level
NONE 1 user id 2 user ids 1 2 user ids 3 2 user ids 2 user ids
READ 1 user id 1 user id 1 user id 1 user id 1 user id
UPDATE 1 user id 1 user id + RESSEC 2 1 user id 1 user id 1 user id
CONTROL No check No check No check No check No check
ALTER No check No check No check No check No check

  1. For CICS, the 2 user ids are the CICS address space user id and the transaction user id.
  2. If the transaction has been defined with RESSEC=YES, then this will also check the transaction user ID (as it would for 2 user id checking).
  3. For IMS the second user id varies according to the type of the dependent region (see How the second user ID is determined for the IMS connection)

User ids for channels

Very like the other hosting environments, the CHINIT address space has a number of user ids in place for the channels which it hosts.


This is the user ID that most people are familiar with on MQ channels. You can assign the MCAUSER by a number of different means which is the subject of another blog post “All the ways to set MCAUSER”. Not surprisingly, this is one of the choices available for authority checks.

Message User ID

Sometimes referred to as the alternate user ID, the UserIdentifier field in the MQMD of the message being moved over the channel is one of the choices. Channels are designed to be a resource shared by many different applications, so not all the messages moving over a channel will be for user ids with the same authority. MQ allows you to determine whether a message is allowed to be put to its target queue based on the credentials inside each individual message instead of treating them all the same which is what happens when you use MCAUSER.


Depending on how your channel is configured you may also have the user ID associated with the certificate or a certificate map held in your ESM when your channel uses SSL/TLS. If you are using LU6.2 then you may have access to the SNA flowed user ID. And finally there is the CHINIT address space user ID which is used if neither of the others are in scope. This collection is sometimes referred to as the channel user ID (CHL).

The way these user ids are used is controlled by two things, the RESLEVEL profile just introduced and an attribute on a receiving type channel called PutAuthority. This attribute is mainly there to allow you to choose between authorizing each message to the target queue by the user id inside the message, or to treat all messages the same and authorize the use of the target queue by the credentials that the channel is running with – ostensibly the MCAUSER. However, on z/OS Put Authority has one further task and that is to allow you to choose to use or ignore the user ID referred to as CHL – the group of Other user ids described above.

I’ve drawn a simplified matrix of all the choices (the full table can be seen in “Receiving channels using TCP/IP”). You will see that there are lots of choices, but actually, there are only really a few sensible ones, and those I have highlighted and will explain below.

One user id Two user ids
Note: Where ALT is used, it is only checked against the resource profile, the others are also checked against the CONTEXT profile (if you have context checks on) and against the ALTERNATE.USER profile if you are using ALT.

Deciding which setup to use

In order to decide which of the many possible setups to choose, I think there are two main questions to ask yourself. The answer to these questions will lead you to the best choice for you.

Question 1: Do you wish to treat each message individually and authorize the channel placing the message on the targeted queue by using the user ID inside the message?

Question 2: Do you wish to include the CHL user ID in your checks?

When answering question 1, remember that to use user IDs from inside messages, these user IDs may not be defined on the target system, depending on where the message originated from. It is a strong security set up to do this, but also one that comes with more work to maintain.

When answering question 2, my personal opinion is that there is no need to be checking the CHINIT started task user ID since it is likely to have the authorities needed already, and you should be aiming for something more granular, something on a per channel basis, and so you should only answer yes if you are using LU6.2 channels with flowed user IDs, or SSL/TLS channels and you have Certificate Name Filters (CNF) set up for the presented certificates from your partner queue managers. Since LU6.2 is rarely used anymore, the main reason for answer yes to question 2 would be the use of CNF and I believe CHLAUTH rules are flexible enough to allow you to set the MCAUSER appropriately based on the DN in the certificate so CNF is not providing any additional value.

All messages the same, not CHINIT region

You have decided to treat each message the same, and use the channel credentials, rather than the credentials inside the message, for the authority check on the target queue. You have decided that the CHINIT started task user ID does not add anything to your security. In short, your authorisation checks are being done using the MCAUSER id. It is wise that you ensure your MCAUSER id is appropriately set up, and you should read up and understand CHLAUTH rules to help you with that.
To set this up, ensure that your CHINIT started task user ID has READ access to the RESLEVEL profile (thus ensuring it is only making 1 check):-

Then define your channels to use PUTAUT(ONLYMCA):-

Authority checked on a per message basis, not CHINIT region

You have decided to treat each message on its own credentials, rather than having all messages be treated the same. You have decided that the CHINIT started task user ID does not add anything to your security. In this case your authorization checks are being done using a combination of MCAUSER (which is checked for authority on the ALTERNATE.USER and CONTEXT profiles – if you are using them) and the user ID in the message (which along with the MCAUSER is checked against the queue profile).

To set this up, ensure that your CHINIT started task user ID has no access to the RESLEVEL profile (thus ensuring that it is making two checks).

Then define your channels to use PUTAUT(ALTMCA):-

Making use of CHL user id (i.e. the CHINIT region ID)

Unless you want everything on your channel to have its authority checks done using the CHINIT region ID (or one of the flowed IDs described earlier in the ‘Other’ section), then you must be doing two checks. The reason for this is if you are checking the CHL user ID at all, it is always the first user ID, and so to get any level of granularity you must check this and the second user ID as well.

To set this up, ensure that your CHINIT started task user ID has no access to the RESLEVEL profile (thus ensuring that it is making two checks).

The remaining set up is then dependant on your answer to question 1, whether you want to use the user id from within each message. If yes, then define your channels to use PUTAUT(CTX):-
Otherwise define your channels to use PUTAUT(DEF):-

Final thought

The RESLEVEL profile is a powerful way to control the security checks that are made in an IBM MQ for z/OS queue manager. Understanding it will ensure that the security checks you intend are being used correctly. Beware turning off all security by granting too much authority to this powerful profile.

[1] For completeness, there is actually two possible RESLEVEL profiles because if you are using Queue-Sharing Group security there is both a qmgr.RESLEVEL and a qsg.RESLEVEL profile that could be in place. I have not covered Queue Sharing Group security in this post.

[2] Or MXADMIN class if you are using mixed case security profiles.

IBM Certified Specialist

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


The team at MQGem would love to hear what you think. Leave your comments here.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.