From IBM MQ for z/OS 9.4, CAPEXPRY becomes a separate, first-class attribute, following its release on Distributed platforms in IBM MQ 9.3.1. This change means administration of CAPEXPRY on your z/OS queue managers is now the same as Distributed queue managers. You can read the release notes in IBM Documentation.
For a full run-down of how the CAPEXPRY attribute co-exists and works with the existing CUSTOM CAPEXPRY attribute, see Vasily’s blog Making CAPEXPRY a first-class MQSC attribute in MQ 9.3.1. The principles for CAPEXPRY on IBM MQ for z/OS are almost identical to the description in his blog. Instead, this blog will focus on the IBM MQ for z/OS specifics.
The new first-class CAPEXPRY attribute is designed to co-exist with any CUSTOM CAPEXPRY values you have set on your queues. When you upgrade a queue manager to IBM MQ for z/OS 9.4, any queues that are available to that queue manager will display the new first-class attribute, along with the existing CUSTOM attribute if you have set it.
Note: on upgrading, the queue manager will set the first-class attribute to the default of NOLIMIT for queues, or ASPARENT for topics. These defaults mean there will be no immediate change in behaviour, as providing the default value enables the CUSTOM attribute to be enforced.
To allow for the co-existence of these two attributes, IBM MQ for z/OS does not allow one to be set whilst the other is a non-default value. For example, with the default NOLIMIT for queues:
Any attempt to set both values will result in the new CSQM531I Cannot set CAPEXPRY as both a first-class and custom attribute message being issued, and no changes to any objects specified.
Shared queues (that is, queues made available to a queue sharing group), cannot have the new first-class CAPEXPRY value set if any queue managers in the queue sharing group are below IBM MQ for z/OS version 9.4. Any attempt to set the first-class value will result in two new messages. A CSQM532I message is issued for every back-level queue manager in the QSG:
CSQM532I Queue manager ‘QM1’ is at version 9.2.0 and does not support attribute ‘CAPEXPRY’
CSQM532I Queue manager ‘QM2’ is at version 9.3.0 and does not support attribute ‘CAPEXPRY’
And finally:
CSQM533I Cannot set ‘CAPEXPRY’, incompatible queue manager versions in this queue-sharing group
Similarly, any attempt to modify the shared queue via PCF command generates a new return code: MQRCCF_INCOMPATIBLE_QMGR_IN_QSG.
Should you decide to backwards migrate your queue manager to an older release of IBM MQ for z/OS, the first-class CAPEXPRY value is removed, and hence the CUSTOM value will once again be enforced. For this reason, we do not recommend using the first-class CAPEXPRY attribute in any queue-sharing group configuration where you anticipate backwards migrating a queue manager, as this may lead to a situation where both the first-class and CUSTOM value are set on the same shared queue. In this situation, the queue managers at IBM MQ for z/OS 9.4 or higher will honour the first-class attribute, whilst older queue managers will honour the CUSTOM attribute, meaning you may encounter two different expiry caps being applied, depending on the queue manager that put the message on the shared queue.
In a publish/subscribe setup, CAPEXPRY is resolved using the standard ASPARENT mechanism, where topic nodes can inherit properties from their parent nodes. The default value for CAPEXPRY is ASPARENT, except for the SYSTEM.BASE.TOPIC where it defaults to NOLIMIT. If all the values for the first-class CAPEXPRY attribute are set to these defaults, the CUSTOM attributes are then queried with the same inheritance mechanism.
Finally, first-class CAPEXPRY is now a clustered attribute, unlike its CUSTOM counterpart. Importantly, this means that IBM MQ for z/OS 9.4 queue managers can now participate as full repositories in clusters where CAPEXPRY is being used, whereas before, this was not possible.
So, that’s about it for the implementation of CAPEXPRY on IBM MQ for z/OS! We appreciate that some of these rules can be confusing. If you have any questions, the development team are always happy to chat.
You can reach out to me via my email: toby.keegan@ibm.com.