MQ

The only reason I can think of that a queue manager would require you to use compatibility mode for authentication is if you have a security exit installed on the queue manager that is checking the user id and password. If this is your situation, then you will need to look at whatever output your security exit writes out to figure out what is is complaining about.

Alternatively, if you do not have a security exit, then we might be able to assist you with understanding the 2035 error, if you can show us what is written in the queue manager's AMQERR01.LOG about the error.

Cheers,
Morag

Hi Morag,

Thank you so much for responding. I've been attempting to get the logs from the vendor, and they are not being helpful. I am able to successfully connect via MQ Explorer with my AIX user ID and password by checking the "User Identification Compatibility Mode" checkbox. Are you familiar with how I would replicate that behavior? 

As back story, I took over managing data transfer operations for a system that processes insurance claims and uses MQ for all it's inbound and outbound transactions. The process their implementation team left in place was to install MQ Visual Edit (basically MQ Explorer) on workstations, and manually copy and paste inbound and outbound files from their queues. Our analysts spend hours of their time every day searching for messages in a glorified version MQ Explorer, copying the message to a text file, then manually naming and saving files to folders where processes in our windows environment can pick them up. When I sent them the ticket requesting logs, their response was to try MQ Visual Edit, so not upbeat about getting any helpful response. 

Any clue about what to try next would be infinitely appreciated.

The only reason I can think of that a queue manager would require you to use compatibility mode for authentication is if you have a security exit installed on the queue manager that is checking the user id and password. If this is your situation, then you will need to look at whatever output your security exit writes out to figure out what is is complaining about.

Alternatively, if you do not have a security exit, then we might be able to assist you with understanding the 2035 error, if you can show us what is written in the queue manager's AMQERR01.LOG about the error.

Cheers,
Morag

Hi Morag,

Thank you so much for responding. I've been attempting to get the logs from the vendor, and they are not being helpful. I am able to successfully connect via MQ Explorer with my AIX user ID and password by checking the "User Identification Compatibility Mode" checkbox. Are you familiar with how I would replicate that behavior? 

As back story, I took over managing data transfer operations for a system that processes insurance claims and uses MQ for all it's inbound and outbound transactions. The process their implementation team left in place was to install MQ Visual Edit (basically MQ Explorer) on workstations, and manually copy and paste inbound and outbound files from their queues. Our analysts spend hours of their time every day searching for messages in a glorified version MQ Explorer, copying the message to a text file, then manually naming and saving files to folders where processes in our windows environment can pick them up. When I sent them the ticket requesting logs, their response was to try MQ Visual Edit, so not upbeat about getting any helpful response. 

Any clue about what to try next would be infinitely appreciated.

The only reason I can think of that a queue manager would require you to use compatibility mode for authentication is if you have a security exit installed on the queue manager that is checking the user id and password. If this is your situation, then you will need to look at whatever output your security exit writes out to figure out what is is complaining about.

Alternatively, if you do not have a security exit, then we might be able to assist you with understanding the 2035 error, if you can show us what is written in the queue manager's AMQERR01.LOG about the error.

Cheers,
Morag

Hi Morag,

Thank you so much for responding. I've been attempting to get the logs from the vendor, and they are not being helpful. I am able to successfully connect via MQ Explorer with my AIX user ID and password by checking the "User Identification Compatibility Mode" checkbox. Are you familiar with how I would replicate that behavior? 

As back story, I took over managing data transfer operations for a system that processes insurance claims and uses MQ for all it's inbound and outbound transactions. The process their implementation team left in place was to install MQ Visual Edit (basically MQ Explorer) on workstations, and manually copy and paste inbound and outbound files from their queues. Our analysts spend hours of their time every day searching for messages in a glorified version MQ Explorer, copying the message to a text file, then manually naming and saving files to folders where processes in our windows environment can pick them up. When I sent them the ticket requesting logs, their response was to try MQ Visual Edit, so not upbeat about getting any helpful response. 

Any clue about what to try next would be infinitely appreciated.

The only reason I can think of that a queue manager would require you to use compatibility mode for authentication is if you have a security exit installed on the queue manager that is checking the user id and password. If this is your situation, then you will need to look at whatever output your security exit writes out to figure out what is is complaining about.

Alternatively, if you do not have a security exit, then we might be able to assist you with understanding the 2035 error, if you can show us what is written in the queue manager's AMQERR01.LOG about the error.

Cheers,
Morag

• MQ Explorer is an IBM supplied tool for MQ administration
• Capitalware's MQ Visual Edit is an MQ message editing tool (no administration ability)

• Java & Java/JMS applications allow you to set the UserId that the applications is running under (aka runtime UserId).  Note: This can be the same or different than the credentials (UserId & Password) that are used by the queue manager or security exit for authentication.
• C/C++/COBOL and .NET uses the UserId that the application is running under (aka runtime UserId).  You cannot override this!!  Note: You can set the authentication credentials (UserId & Password) that are used by the queue manager or security exit for authentication but this has NO bearing on the setting of the runtime UserId.

1. Have the MQAdmin turn on authentication for the channel you are using and set the queue manager's  AdoptCTX to Yes. In your program, you set USE_MQCSP_AUTHENTICATION_PROPERTY to true and set your credentials (UserId & Password).  Once, authentication is successful, because ADOPTCTX is set to Yes, the queue manager will use the credential UserId and not the runtime UserId for authorization checks.
2. Get your Windows UserId added to the AIX server and have the appropriate MQ permissions added to your Windows UserId.
3. Have the MQAdmin create a separate channel for you and then set your AIX UserId in the channel's MCAUSER field.
4. On Windows, use the Windows runas command but this means adding your AIX UserId to your Windows PC.

Hi Morag,

Thank you so much for responding. I've been attempting to get the logs from the vendor, and they are not being helpful. I am able to successfully connect via MQ Explorer with my AIX user ID and password by checking the "User Identification Compatibility Mode" checkbox. Are you familiar with how I would replicate that behavior? 

As back story, I took over managing data transfer operations for a system that processes insurance claims and uses MQ for all it's inbound and outbound transactions. The process their implementation team left in place was to install MQ Visual Edit (basically MQ Explorer) on workstations, and manually copy and paste inbound and outbound files from their queues. Our analysts spend hours of their time every day searching for messages in a glorified version MQ Explorer, copying the message to a text file, then manually naming and saving files to folders where processes in our windows environment can pick them up. When I sent them the ticket requesting logs, their response was to try MQ Visual Edit, so not upbeat about getting any helpful response. 

Any clue about what to try next would be infinitely appreciated.

The only reason I can think of that a queue manager would require you to use compatibility mode for authentication is if you have a security exit installed on the queue manager that is checking the user id and password. If this is your situation, then you will need to look at whatever output your security exit writes out to figure out what is is complaining about.

Alternatively, if you do not have a security exit, then we might be able to assist you with understanding the 2035 error, if you can show us what is written in the queue manager's AMQERR01.LOG about the error.

Cheers,
Morag

1. Have the MQAdmin turn on authentication for the channel you are using and set the queue manager's  AdoptCTX to Yes. In your program, you set USE_MQCSP_AUTHENTICATION_PROPERTY to true and set your credentials (UserId & Password).  Once, authentication is successful, because ADOPTCTX is set to Yes, the queue manager will use the credential UserId and not the runtime UserId for authorization checks.

I know this is an old post, but can you tell me how to do the following in a C# .NET program:
1. queue manager's  AdoptCTX to Yes

2. set USE_MQCSP_AUTHENTICATION_PROPERTY to true

I've already got this:
                Hashtable props = new Hashtable();
                props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
                props.Add(MQC.HOST_NAME_PROPERTY, _mQConfiguration.HostName);
                props.Add(MQC.CHANNEL_PROPERTY, _mQConfiguration.ChannelName);
                props.Add(MQC.PORT_PROPERTY, _mQConfiguration.HostPort);
                props.Add(MQC.USER_ID_PROPERTY, "SERVICEACCOUNT");
                props.Add(MQC.PASSWORD_PROPERTY, "");
                _mqQMgr = null;
                _mqQMgr = new MQQueueManager(_mQConfiguration.QueueMgr, props);

I assume it isn't:

props.Add(MQC.MQADPCTX_YES, 1);
props.Add(MQC.USE_MQCSP_AUTHENTICATION_PROPERTY, true);

• MQ Explorer is an IBM supplied tool for MQ administration
• Capitalware's MQ Visual Edit is an MQ message editing tool (no administration ability)

• Java & Java/JMS applications allow you to set the UserId that the applications is running under (aka runtime UserId).  Note: This can be the same or different than the credentials (UserId & Password) that are used by the queue manager or security exit for authentication.
• C/C++/COBOL and .NET uses the UserId that the application is running under (aka runtime UserId).  You cannot override this!!  Note: You can set the authentication credentials (UserId & Password) that are used by the queue manager or security exit for authentication but this has NO bearing on the setting of the runtime UserId.

1. Have the MQAdmin turn on authentication for the channel you are using and set the queue manager's  AdoptCTX to Yes. In your program, you set USE_MQCSP_AUTHENTICATION_PROPERTY to true and set your credentials (UserId & Password).  Once, authentication is successful, because ADOPTCTX is set to Yes, the queue manager will use the credential UserId and not the runtime UserId for authorization checks.
2. Get your Windows UserId added to the AIX server and have the appropriate MQ permissions added to your Windows UserId.
3. Have the MQAdmin create a separate channel for you and then set your AIX UserId in the channel's MCAUSER field.
4. On Windows, use the Windows runas command but this means adding your AIX UserId to your Windows PC.

Hi Morag,

Thank you so much for responding. I've been attempting to get the logs from the vendor, and they are not being helpful. I am able to successfully connect via MQ Explorer with my AIX user ID and password by checking the "User Identification Compatibility Mode" checkbox. Are you familiar with how I would replicate that behavior? 

As back story, I took over managing data transfer operations for a system that processes insurance claims and uses MQ for all it's inbound and outbound transactions. The process their implementation team left in place was to install MQ Visual Edit (basically MQ Explorer) on workstations, and manually copy and paste inbound and outbound files from their queues. Our analysts spend hours of their time every day searching for messages in a glorified version MQ Explorer, copying the message to a text file, then manually naming and saving files to folders where processes in our windows environment can pick them up. When I sent them the ticket requesting logs, their response was to try MQ Visual Edit, so not upbeat about getting any helpful response. 

Any clue about what to try next would be infinitely appreciated.

The only reason I can think of that a queue manager would require you to use compatibility mode for authentication is if you have a security exit installed on the queue manager that is checking the user id and password. If this is your situation, then you will need to look at whatever output your security exit writes out to figure out what is is complaining about.

Alternatively, if you do not have a security exit, then we might be able to assist you with understanding the 2035 error, if you can show us what is written in the queue manager's AMQERR01.LOG about the error.

Cheers,
Morag