I would strongly suggest you contact Capitalware Support.
It appears you have configured & are using the client-side security exit for MQ Authenticate User Security Exit (MQAUSX) and I presume that the z/OS MQAUSX server-side security exit is fully configured.
Application in production located on the same host as MQ and uses binding mode (no password, only user ID which is MVS user ID)
That comment does not make any sense. So, you are running the Java application on z/OS in the same LPAR as the z/OS queue manager? Also, in Bindings mode, the MQ client library does not use a channel, hence, a channel security exit would not be invoked.
If I intentionally use the wrong user ID or password I get a different error: Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9204
The reason code of 2009 means that the MQAUSX server-side security exit shutdown the channel. i.e. Failed authenication.
You said that you switched from using MQ v8.0 to the latest MQ CSD 9.4.1.0 but IBM has made changes to the underlining handling of UserId sent between the client-side to the server-side queue manager. I'm willing to bet you are getting burnt by this.
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
It appears that your application's UserId & Password were successfully authenticated by the MQAUSX server-side security exit but failed on RACF/ACF2 authorization for "connecting to the queue manager" or "opening a queue" because the UserId being used for authorization is mismatched.
Ask your z/OS MQAdmin to check the MQAUSX log file to see what MQAUSX outputted It will have a detailed output for the authenticated UserId and the UserId used for accessing the z/OS queue manager. Also, ask the z/OS MQAdmin if the queue manager's log file recorded the RC of 2035 & what was in the error message.
Finally, did you switch channel names to connect to the z/OS queue manager? If so, what value is in the MCAUSER field of the old channel and new channel?