IBM MQ Little Gem #25: MCAUSER(*)

This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.

If you're familiar with the DISPLAY CHSTATUS command, you may have noticed that one of the fields output is the MCAUSER. This has become more useful in recent years with more features that allow you to set the MCAUSER for the SVRCONN channel to run with. A good summary of all these different ways of setting the MCAUSER can be found in All the ways to set MCAUSER. It is very handy to be able to use the DISPLAY CHSTATUS command to see which MCAUSER the channel has ended up being given.

MCAUSER Asterisk.jpgSometimes though, you might see the MCAUSER field containing a single asterisk. That is what this post is about.

MCAUSER(*) was introduced into IBM MQ at the same time as SHARECNV. When you are sharing multiple conversations over a single SVRCONN channel, those connections may not all be assigned the same MCAUSER value to run with. In the case where they are not, then MCAUSER(*) will be shown.

Examples

I'll start by showing some examples of different connection scenarios.

Single Connection

AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(1) 
   MAXSHCNV(10)                            RPRODUCT(MQCC)

In the above example, there is only one connection using the channel (even though more would be allowed) and so therefore the MCAUSER field shows the value assigned to that single connection. You will never see MCAUSER(*) in this situation.

Two connections sharing a channel

AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(mqgemusr)                       STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(2) 
   MAXSHCNV(10)                            RPRODUCT(MQJM)  

In the above example, there are two connections, from a Java client, sharing the same channel. However, both of these connections have been assigned the same MCAUSER, and so the output shows that user id.

Two connections using different users sharing a channel

AMQ8417: Display Channel Status details.
   CHANNEL(MQGEM.SVRCONN)                  CHLTYPE(SVRCONN)
   CONNAME(127.0.0.1)                      CURRENT
   MCAUSER(*)                              STATUS(RUNNING)
   SUBSTATE(RECEIVE)                       CURSHCNV(2) 
   MAXSHCNV(10)                            RPRODUCT(MQCC) 

In the above example, there are two connections, from a 'C' client, sharing the same channel. This time you see MCAUSER(*) since these two connections have not been assigned the same user id.

How to get connections with different user ids

Normally all your applications are likely to run using the same user id. Perhaps you map the MCAUSER on the SVRCONN based on the contents of a digital certificate, or perhaps the application provides a user id and password and that is the user id you use. There are other ways to set the MCAUSER as described in the blog post referenced at the beginning of this article.

In order to have a situation where the connections sharing a channel are assigned a different MCAUSER, and thus you see MCAUSER(*) on the DISPLAY CHSTATUS output, one of the following must happen.

  • The user id and password provided on the connection was different for each connection, and was ADOPTed by the MCAUSER rather than ignored and mapped to something based on IP address or digital certificate.
  • SVRCONN Security Exit sets a different MCAUSER for each connection.
  • CHLAUTH USERMAP rule with ChlauthEarlyAdopt=y set maps to a different MCAUSER due to a different user id and password being sent.

These scenarios are possible from any language client, it is not just the case that Java or JMS clients do this. It is certainly more common that JMS clients cause more than one connection to be shared on a SVRCONN channel because of the nature of the way those applications work, but it is not the only way you can see such a thing happening.

How to see the actual value of MCAUSER

When you have a set of connections sharing a channel, and you see MCAUSER(*), how can you determine what the actual MCAUSER values in use are?

Looking at my third example above, in order to see which user ids are in use for these connections, you can use the following command:-

DISPLAY CONN(*) TYPE(ALL) WHERE(CHANNEL EQ MQGEM.SVRCONN)

Which will show you output like this (trimmed a little):-

AMQ8276: Display Connection details.
   CONN(3128755920002C01)                
   EXTCONN(414D51434D5147312020202020202020)
   APPLDESC(WebSphere MQ Channel)          APPLTAG(C:\MQGem\mqmonntp.exe)
   CHANNEL(MQGEM.SVRCONN)                  CONNAME(127.0.0.1)                   
   CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_SHARED_BINDING)
   USERID(morag) 
AMQ8276: Display Connection details.
   CONN(3128755920002B01)                
   EXTCONN(414D51434D5147312020202020202020)
   APPLDESC(WebSphere MQ Channel)          APPLTAG(C:\MQGem\mqmonntp.exe)
   CHANNEL(MQGEM.SVRCONN)                  CONNAME(127.0.0.1)                   
   CONNOPTS(MQCNO_HANDLE_SHARE_BLOCK,MQCNO_SHARED_BINDING)
   USERID(mqgemusr) 

You can see that each connection has a different USERID which is what has resulted in the MCAUSER(*) on the DISPLAY CHSTATUS output.

So even when you see MCAUSER(*), you can always still work out which user ids are in use by using the DISPLAY CONN command.


There was a recent IBM MQ APAR, IT09665: MCAUSER is set to '*' when all incoming users are mapped to the same user ID which may mean that you see MCAUSER(*) when you shouldn't. With the information in this article, you now know how to determine whether you are afflicted by this defect, or whether you truly have different values for MCAUSER.


Morag Hughson is an MQ expert. She spent 18 years in the MQ Devt organisation before taking on her current job writing MQ Technical education courses with MQGem. She also blogs for MQGem. You can connect with her here on IMWUC or on Twitter and LinkedIn.
0 Comments
Recent Stories
IBM MQ Little Gem #28: EVENT Switches

IBM MQ Little Gem #27: strmqtrc

IBM MQ Little Gem #26: Publish Delivery Options