Upgrading CA Gen 8.0 MQ Java Proxy to 8.6 and receiving return code 2035 (MQRC_NOT_AUTHORIZED) for the dynamic reply queue because it is trying to be created with name QMGR_NAME.xxxxxx instead of the required name A.B.xxxxxx. With "CMIDEBUG=ON" enabled in the file commcfg.properties the resulting trace.out file shows:
===
11/29/19-09:12:35:786[main]: MQSDynamicCoopFlow.doFlow(): ReplyModelQName (before exit)
11/29/19-09:12:35:786[main]: A.B.REPLY.MODEL
...
11/29/19-09:12:35:787[main]: MQSDynamicCoopFlow.doFlow(): ReplyModelQName (after exit)
11/29/19-09:12:35:787[main]: A.B.REPLY.MODEL
11/29/19-09:12:35:787[main]: MQSDynamicCoopFlow.doFlow(): DynamicQName (after exit)
11/29/19-09:12:35:787[main]: *
...
11/29/19-09:12:36:193[main]: MQSQMgrConnection::getGetQueue(): Creating new GET queue for A.B.REPLY.MODEL
11/29/19-09:12:36:463[main]: MQSDynamicCoopFlow.getMQExceptionData(): entered
11/29/19-09:12:36:463[main]: MQSDynamicCoopFlow.getMQExceptionData(): exited
11/29/19-09:12:36:463[main]: MQSQMgrConnection::getGetQueue(): Failed to open GET queue ( reasonCode = MQRC_NOT_AUTHORIZED, completionCode = MQCC_FAILED, MQEnvironment = (....,1414,) )
===

Release : 8.6
Component : CA Gen Run Time, Proxies

The error is due to not customising the Gen 8.6 Java Proxy user exit MQSDynamicCoopFlowExit.java method getDynamicQName() in the same way that it was done in Gen 8.0.

Comparing trace files for working Gen 8.0 Java Proxy and non-working Gen 8.6 Java Proxy:

1. For Gen 8.0 the DynamicQName is returning value "A.B.*" from the user exit MQSDynamicCoopFlowExit.java:
===
12/04/19-10:18:48:313[main]: MQSDynamicCoopFlow.doFlow(): ReplyModelQName (after exit)
12/04/19-10:18:48:313[main]: A.B.REPLY.MODEL
12/04/19-10:18:48:313[main]: MQSDynamicCoopFlow.doFlow(): DynamicQName (after exit)
12/04/19-10:18:48:313[main]: A.B.*
===
That is then used successfully later:
===
12/04/19-10:18:49:374[main]: MQSQMgrConnection::getGetQueue(): Creating new GET queue for A.B.REPLY.MODEL
12/04/19-10:18:49:724[main]: MQSDynamicCoopFlow::doFlow(): returned dynamic reply queue name
12/04/19-10:18:49:725[main]: A.B.xxxxxx 
===
It was found that the Gen 8.0 user exit MQSDynamicCoopFlowExit.java method DynamicQName had been customised to take the value of ReplyModelQName and return a value based on that.

2. For Gen 8.6 the DynamicQName is returning value its default value of "*" from the user exit MQSDynamicCoopFlowExit.java:
===
11/29/19-09:12:35:787[main]: MQSDynamicCoopFlow.doFlow(): ReplyModelQName (after exit)
11/29/19-09:12:35:787[main]: A.B.REPLY.MODEL
11/29/19-09:12:35:787[main]: MQSDynamicCoopFlow.doFlow(): DynamicQName (after exit)
11/29/19-09:12:35:787[main]: *
===
Per the user exit comments "The default value is a '*' which means that a fully MQ generated name will be used."
That then fails later because MQ is trying to use a generated reply queue name based on Queue Manager name QMGR_NAME for which there is no authorization:
===
11/29/19-09:12:36:193[main]: MQSQMgrConnection::getGetQueue(): Creating new GET queue for A.B.REPLY.MODEL
11/29/19-09:12:36:463[main]: MQSDynamicCoopFlow.getMQExceptionData(): entered
11/29/19-09:12:36:463[main]: MQSDynamicCoopFlow.getMQExceptionData(): exited
11/29/19-09:12:36:463[main]: MQSQMgrConnection::getGetQueue(): Failed to open GET queue ( reasonCode = MQRC_NOT_AUTHORIZED, completionCode = MQCC_FAILED, MQEnvironment = (....,1414,) )
===

Customising the Gen 8.6 user exit MQSDynamicCoopFlowExit.java method DynamicQName in the same way as Gen 8.0 resolved the problem.

NOTE: It is not possible to configure a Dynamic Reply Queue using the commcfg.properties file and it must be done by editing the Gen Java user exit MQSDynamicCoopFlowExit.java which contains method getDynamicQName(). More details here:
"Preparing for Execution of Java Proxy (Classic Style) Application" - see "Communications User Exits"
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/devops/ca-gen/8-6/distributed-processing/working-with-proxies/java-proxy-classic-style/preparing-for-execution-of-java-proxy-classic-style-application.html

"Preparing for Executing a Java Proxy Application" - see "Communications User Exits":
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/devops/ca-gen/8-6/distributed-processing/working-with-proxies/java-proxy/preparing-for-executing-a-java-proxy-application.html