App Connect

I have a customer who just upgraded one legacy IIB broker from v10.0.0.8 to v10.0.0.25.

After the upgrade, a working flow which started with an MQ Input node and included an MQ Output node started failing. It worked correctly on v10.0.0.8. The failure was MQRC 2035, and the MQ error log reported that the 'setid' permission was required, but not granted.

We are using LDAP for authentication, so the iib run time user is not a member of the mqm group.

The iib user has put, inq, setall, dsp permissions granted (as documented in the manual), which was sufficient in v10.0.0.8, but we had to add setid to permit it to run in v10.0.0.25.

I was unable to find any reference to a change in MQ permissions or context settings in the IIB Fix List, so I though I would ask here. Does anyone know if there was a change made during the lifetime of IIB v10 so that MQ Output node might required setid permission rather than setall? It's not urgent, as we are just granting the new authority based on the message, so it's not stopping our progress, but I was hoping to get confirmation that it is an expected (if apparently undocumented) behaviour change.

Regards.

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-22
------------------------------

HI @Neil Casey thank you for your post!
Here is what I was able to gather from the team:

"This is likely because of apar IT21537.
At 10.0.0.8, then we always try and open the queue with:
MQLONG  openOptions = MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING + MQOO_SET_ALL_CONTEXT;
which would have required setall permissions.The apar fixed it so that we only ask for the options that we need. Previously customers would have had to grant +setall to make it work, which is more permissive than the +passall, which we now request.
Going forward, the customer will now need to add the +passall option to their users security on the queue."
​

------------------------------
Jina K
------------------------------

Original Message:
Sent: Tue May 03, 2022 09:19 PM
From: Neil Casey
Subject: Can an IIB upgrade change the required permission to put to a queue?

I have a customer who just upgraded one legacy IIB broker from v10.0.0.8 to v10.0.0.25.

After the upgrade, a working flow which started with an MQ Input node and included an MQ Output node started failing. It worked correctly on v10.0.0.8. The failure was MQRC 2035, and the MQ error log reported that the 'setid' permission was required, but not granted.

We are using LDAP for authentication, so the iib run time user is not a member of the mqm group.

The iib user has put, inq, setall, dsp permissions granted (as documented in the manual), which was sufficient in v10.0.0.8, but we had to add setid to permit it to run in v10.0.0.25.

I was unable to find any reference to a change in MQ permissions or context settings in the IIB Fix List, so I though I would ask here. Does anyone know if there was a change made during the lifetime of IIB v10 so that MQ Output node might required setid permission rather than setall? It's not urgent, as we are just granting the new authority based on the message, so it's not stopping our progress, but I was hoping to get confirmation that it is an expected (if apparently undocumented) behaviour change.

Regards.

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-22
------------------------------

Thanks for the reply Jina,

I figured it would be something like that, but when I went through the fixes I couldn't find one that matched.

It seems that the manuals might not have caught up with the new requirements, and that sometimes permissions other than passall (in my case we needed +setid) are also needed.

Thanks again.

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-22
------------------------------

Original Message:
Sent: Thu May 12, 2022 10:20 AM
From: Jina K
Subject: Can an IIB upgrade change the required permission to put to a queue?

HI @Neil Casey thank you for your post!
Here is what I was able to gather from the team:

"This is likely because of apar IT21537.
At 10.0.0.8, then we always try and open the queue with:
MQLONG  openOptions = MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING + MQOO_SET_ALL_CONTEXT;
which would have required setall permissions.The apar fixed it so that we only ask for the options that we need. Previously customers would have had to grant +setall to make it work, which is more permissive than the +passall, which we now request.
Going forward, the customer will now need to add the +passall option to their users security on the queue."
​

------------------------------
Jina K

Original Message:
Sent: Tue May 03, 2022 09:19 PM
From: Neil Casey
Subject: Can an IIB upgrade change the required permission to put to a queue?

I have a customer who just upgraded one legacy IIB broker from v10.0.0.8 to v10.0.0.25.

After the upgrade, a working flow which started with an MQ Input node and included an MQ Output node started failing. It worked correctly on v10.0.0.8. The failure was MQRC 2035, and the MQ error log reported that the 'setid' permission was required, but not granted.

We are using LDAP for authentication, so the iib run time user is not a member of the mqm group.

The iib user has put, inq, setall, dsp permissions granted (as documented in the manual), which was sufficient in v10.0.0.8, but we had to add setid to permit it to run in v10.0.0.25.

I was unable to find any reference to a change in MQ permissions or context settings in the IIB Fix List, so I though I would ask here. Does anyone know if there was a change made during the lifetime of IIB v10 so that MQ Output node might required setid permission rather than setall? It's not urgent, as we are just granting the new authority based on the message, so it's not stopping our progress, but I was hoping to get confirmation that it is an expected (if apparently undocumented) behaviour change.

Regards.

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-22
------------------------------