Does the CAPEXPRY parameter permanently change the expiry of the message?

If you use CAPEXPRY on a queue, it caps the expiry of any message on the queue to the value you choose (in 10ths of a second).

My question is, once the message leaves that queue again, does it still have the capped expiry? i.e. does CAPEXPRY permanently change the message, or just cap the expiry while it's on that queue?

Likewise, if you use CAPEXPRY on a topic, does that change the message header for the messages sent to all subscribers?

Solution

Summary:

The Expiry value will remain on the MQMD when the message leaves the queue and is the remaining time, if it lands on another queue it can be decreased by that queue's CAPEXPRY, if an application GETs the message it can look at Expiry to check how much time was remaining.
If CAPEXPRY is set on a TOPIC object then all messages published that resolve to that TOPIC object will have the expiry set to that value unless they were published with a lower expiry.

At 8.0.0.4 - 9.3.0.x (LTS) CAPEXPRY was a CUSTOM attribute and can be applied to all queue types and topics. At 9.3.1 (CD) and later it is now a normal attribute.

Expiry is a field in the MQMD (Message Descriptor) set at PUT time. Expiry will count down and will transfer with the message, and can be decreased when PUT to subsequent downstream queues by CAPEXPRY.

CAPEXPRY can only decrease the Expiry, it will not increase it.

If you had the following setup and PUT to the QREMOTE, the message on the QLOCAL will end up with the lower value of 600 unless it was delayed on the XMITQ for longer than 5400 10s of a second in which case the remaining Expiry at the time it is PUT to the QLOCAL would be less than 600 and would not be impacted by the CAPEXPRY. (Assumes you did not set the Expiry at PUT time to a value lower than 600)

QMGR1: QREMOTE(QUEUE.QR) RNAME(QUEUE.QL) RQMNAME(QMGR2) CAPEXPRY(6000)
QMGR2: QLOCAL(QUEUE.QL) CAPEXPRY(600)

References: