The RESLEVEL profile

When an application tries to connect to WebSphere MQ, WebSphere MQ checks the access that the user ID associated with the connection has to a profile in the MQADMIN class called:

hlq.RESLEVEL

where

hlq can be either ssid (subsystem ID) or qsg (queue-sharing group ID).

The user IDs associated with each connection type are:

If you are using queue manager level security only, WebSphere MQ performs RESLEVEL checks against the

qmgr-name.RESLEVEL profile. If you are using queue-sharing group level security only, WebSphere MQ performs RESLEVEL checks against the

qsg-name.RESLEVEL profile. If you are using a combination of both queue manager and queue-sharing group level security, WebSphere MQ first checks for the existence of a RESLEVEL profile at queue manager level. If it does not find one, it checks for a RESLEVEL profile at queue-sharing group level.

If it cannot find a RESLEVEL profile, WebSphere MQ enables checking of both the job and task (or alternate user) ID for a CICS or an IMS connection. For a batch connection, WebSphere MQ enables checking of the job (or alternate) user ID. For the channel initiator, WebSphere MQ enables checking of the channel user ID and the MCA (or alternate) user ID.

If there is a RESLEVEL profile, the level of checking depends on the environment and access level for the profile.

Remember that if your queue manager is a member of a queue-sharing group and you do not define this profile at queue-manager level, there might be one defined at queue-sharing group level that will effect the level of checking. To activate the checking of two user IDs, you should define a RESLEVEL profile (prefixed with either the queue manager name of the queue-sharing group name) with a UACC(NONE) and ensure that the relevant users do not have access granted against this profile.