Enforcing lower expiration times
Administrators can limit the expiry time of any message put to a queue or topic by using the CAPEXPRY attribute specified in the CUSTOM attribute on the queue or topic.
An expiry time specified in the Expiry field of the MQMD, by an application,which is greater than the CAPEXPRY value specified in the CUSTOM attribute 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.
For example, 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.