Hi Forum,

I am aware that for MQMQ Expiry, the below holds true:

After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired.

How would the internals work for CAPEXPRY?

CAPEXPRY works just like an expiry override. If the expiry is greater than the capexpry value when the message gets put to the queue the capexpry value becomes the expiry value of the message.

If the expiry of the message is less than the capexpry, the message keeps its expiry value.

Hi Forum,

I am aware that for MQMQ Expiry, the below holds true:

After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired.

How would the internals work for CAPEXPRY?

Thanks.

For EXPIRY, there must be a browse or non-browse get to trigger the action.

What would this trigger be for CAPEXPRY?

CAPEXPRY works just like an expiry override. If the expiry is greater than the capexpry value when the message gets put to the queue the capexpry value becomes the expiry value of the message.

If the expiry of the message is less than the capexpry, the message keeps its expiry value.

Hi Forum,

I am aware that for MQMQ Expiry, the below holds true:

After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired.

How would the internals work for CAPEXPRY?

Thanks.

For EXPIRY, there must be a browse or non-browse get to trigger the action.

What would this trigger be for CAPEXPRY?

CAPEXPRY works just like an expiry override. If the expiry is greater than the capexpry value when the message gets put to the queue the capexpry value becomes the expiry value of the message.

If the expiry of the message is less than the capexpry, the message keeps its expiry value.

Hi Forum,

I am aware that for MQMQ Expiry, the below holds true:

After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired.

How would the internals work for CAPEXPRY?

Hi Forum,

I am aware that for MQMQ Expiry, the below holds true:

After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired.

How would the internals work for CAPEXPRY?

------------------------------
Emile Kearns
------------------------------

I suspect that you are misreading this as "The message is discarded ONLY when a browse or non-browse MQGET call occurs ..."  This was the case in pre-V6 MQ.  If memory serves ... a long-ago post on mqseries.net about 'millions of expired messages on a queue and slow response time'.  

mq.ini file TuningParameters:

ExpiryInterval Indicates the frequency with which the queue manager scans the queues looking for expired messages that have not already been cleaned up by other queue activities. It is a time interval in seconds.

------------------------------
bruce2359
Consultant/trainer
CTTECH - Computer & Telecommunications Technology
West Coast, almost
000-000-0000

Original Message:
Sent: Tue August 12, 2025 06:31 AM
From: Emile Kearns
Subject: MQMD Expiry vs CapExpry

Hi Forum,

I am aware that for MQMQ Expiry, the below holds true:

After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired.

How would the internals work for CAPEXPRY?

------------------------------
Emile Kearns
------------------------------

My memory of this code is a bit hazy these days, but I think both the above viewpoints are a little over simplified.

The statement "The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired" is true and has always been true for all versions of MQ on all platforms. The distributed platforms didn't originally support an expiry task, and while that was fixed long ago my recollection is that the expiry task isn't guaranteed to expire any expirable messages. If I remember correctly, if a queue hasn't been loaded into memory since the last queuemanager restart,  then the expiry task won't actually load the queue in order to expire any old messages. When a queue is "loaded" an index is constructed in memory which requires the MQMD for every message on the queue to be read from disk, as part of this loading process the earliest possible expiry time for a message on that queue is determined and thus the expiry task tries to avoid scanning queues on which no expired messages exist. The frequency with whch queues (and in particular deep queues) are loaded/unloaded is something that has been improved over time (for example the queue manager is now more reluctant to unload a deep queue than a shallow queue) and I wouldn't be surprised if further improvements have happened in this area since I retired. 

I suspect that you are misreading this as "The message is discarded ONLY when a browse or non-browse MQGET call occurs ..."  This was the case in pre-V6 MQ.  If memory serves ... a long-ago post on mqseries.net about 'millions of expired messages on a queue and slow response time'.  

mq.ini file TuningParameters:

ExpiryInterval Indicates the frequency with which the queue manager scans the queues looking for expired messages that have not already been cleaned up by other queue activities. It is a time interval in seconds.

------------------------------
bruce2359
Consultant/trainer
CTTECH - Computer & Telecommunications Technology
West Coast, almost
000-000-0000

Original Message:
Sent: Tue August 12, 2025 06:31 AM
From: Emile Kearns
Subject: MQMD Expiry vs CapExpry

Hi Forum,

I am aware that for MQMQ Expiry, the below holds true:

After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired.

How would the internals work for CAPEXPRY?

------------------------------
Emile Kearns
------------------------------

I suspect that you are misreading this as "The message is discarded ONLY when a browse or non-browse MQGET call occurs ..."  This was the case in pre-V6 MQ.  If memory serves ... a long-ago post on mqseries.net about 'millions of expired messages on a queue and slow response time'.  

mq.ini file TuningParameters:

ExpiryInterval Indicates the frequency with which the queue manager scans the queues looking for expired messages that have not already been cleaned up by other queue activities. It is a time interval in seconds.

------------------------------
bruce2359
Consultant/trainer
CTTECH - Computer & Telecommunications Technology
West Coast, almost
000-000-0000

Original Message:
Sent: Tue August 12, 2025 06:31 AM
From: Emile Kearns
Subject: MQMD Expiry vs CapExpry

Hi Forum,

I am aware that for MQMQ Expiry, the below holds true:

After a message's expiry time has elapsed, it becomes eligible to be discarded by the queue manager. The message is discarded when a browse or non-browse MQGET call occurs that would have returned the message had it not already expired.

How would the internals work for CAPEXPRY?

------------------------------
Emile Kearns
------------------------------