Enforcing lower expiration times

Important: You cannot use the CAPEXPRY attribute introduced in IBM® MQ 9.3.1 with a cluster if the full repository is on z/OS®.

From IBM MQ 9.3.1, administrators can limit the expiry time by using the CAPEXPRY attribute of a queue or topic without needing to specify it inside the CUSTOM attribute. If a queue or topic already has the CAPEXPRY attribute set inside the CUSTOM attribute you must remove the CAPEXPRY attribute from the CUSTOM attribute before the new CAPEXPRY attribute is modified. You can do this in a single command, for example:

ALTER QLOCAL(Q1) CAPEXPRY(1000) CUSTOM('')

Note: When you migrate an object from an earlier version of the product, your CAPEXPRY value is set to the default value of NOLIMIT. If the CAPEXPRY attribute was set inside the CUSTOM attribute, this option takes precedence.

If you want to use the new CAPEXPRY attribute, you must remove the CAPEXPRY attribute from the CUSTOM attribute first. Setting both options does not work.

The revised CAPEXPRY attribute set directly on queues or topics (not inside the CUSTOM attribute) is a clustered attribute. Note, that all instances of a cluster queue should use the same value for their CAPEXPRY attribute. It is still possible that a transmission queue will reduce the expiry time of a message if CAPEXPRY has been set on the transmission queue, and the value is lower than the CAPEXPRY attribute of the cluster queue.

An expiry time specified in the Expiry field of the MQMD, by an application,which is greater than the CAPEXPRY value specified on the queue or topic will be replaced by that CAPEXPRY value. An expiry time specified by an application, which is lower than the CAPEXPRY value will be used.

Note that the value of CAPEXPRY is expressed in tenths of seconds, so one minute has a value of 600.

If more than one object is used on the resolution path, for example, when a message is put to an alias or remote queue, then the lowest of all the CAPEXPRY values is used as the upper limit for message expiry.

Changes to the CAPEXPRY values take effect immediately. The expiry value is evaluated for each put to a queue or topic and so is sensitive to the object resolution, which may differ between each put operation.

However, note that existing messages in the queue, prior to a change in CAPEXPRY, are not affected by the change (that is, their expiry time remains intact). Only new messages that are put into the queue after the change in CAPEXPRY have the new expiry time.

In a cluster where a put is performed to a queue opened with MQOO_BIND_NOT_FIXED, messages can be assigned different expiry values on each put, depending on the CAPEXPRY value set for the transmission queue, used by the channel, that sends the message to the selected target queue manager.

Note that a put to a queue or topic by a JMS application specifying a delivery delay fails with MQRC_EXPIRY_ERROR, if the delivery delay is beyond the resolved expiry time for the target queue or topic. A CAPEXPRY attribute set on a queue resolved for a JMS destination can cause this error.