Can you explain how the channel is configured - are you using CHLAUTH feature to restrict MCAUser ?

Here is an article about securing a channel:

My tool set always the MCAUser of the channel to the user id you provided, with the help of a security exit. This was introduced to support zOS RACF authentication.  Now, seems that you have a different way of securing your channel.

Can I ask you to read the article and tell me in which case you are ?

Did you try to put the <dot> password along with the user id, instead of no password ?

The mq client version depends.  If you run the tool on a machine with MQ installed locally, it will use that version. Otherwise, it will use the version provided with the tool that is version 9.0.0.0.

As we now understand it's a Unix machine having the queue manager running on it, from the basic tests I did regarding connectivity, I had to always provide a password with the user id... can you explain how we can set up an environment with this kind of security configuration, so MQ doesn't require a password for user authentication ?

hooo! I missed that one. I was going in the wrong direction. Thank you Zoran to point this out!

Thank you Zoran!

Can we have a extract of the zOS log ? sometimes Websphere MQ provides some clues for helping us... sorry but I'm a bit "blind" without the zOS logs...  The error is returned by the queue manager, so we need to see the queue manager logs to find out why he refused the access.  Is your queue manager configured to simply use the MCAUser on the channel ? can you try by using/creating another channel ?

Is it a standard RACF system for authentication ?

I think copy-pasting the log file content to this thread has truncated it.  Can you send the file by e-mail to support_mqexplorerplus@dotconsulting.be ?

Thank you.

Without detail information reported by the queue manager on zOS, it will be difficult to find out why you have an "access denied" error. Can you contact someone who can have a look at the logs on the mainframe ?