When JAVA Guaranteed Message Delivery to Kafka queues Maximum Queue Depth is set high, MQ does not provide enough precision to alert for a production issue in a timely manner

ISSUE:
One of our Customer's JAVA Guaranteed Message Delivery to Kafka queues Maximum Queue Depths are set high (and about to get higher), due to a requirement to store 36 hours of messages in the event of an extended destination outage. The minimum 1% Queue Depth High Threshold value does not provide enough precision to alert for a production issue in a timely manner when the Maximum Queue Depth value is set high e.g. 1 % of 10,000,000 = Minium Queue Depth Hi Threshold of 100,000. 

NOTE:
1% of 999,999,999 is 9,999,999. For MQSC0512W Highwater Mark alert on 50 messages, a Queue Depth High Threshold value of 0.00000005 would be required.

MQSC0512W QUEUEqname HIGHWATER MARK nummsg WAS EXCEEDED BY numover

JUSTIFICATION:
On 9/14/24, one of our Customers loaded a JAM config file and dropped the KAFKA.INPUT.QUEUE queue from the configuration. The customer didn’t realize it for several hours until monitoring alerted on lower than normal SWBs. There were no JAM errors. The only MQ alert was a Sweep Message and the customer gets those at other times. In addition, the Sweep message did not occur until 48:42 minutes after the JAM was started:

JAMC0001I 21.50.06 JAM tpfmail IS STARTING.+
MQSC0801I 22.38.48 SWEEP FOR KAFKA.INPUT.QUEUE COMPLETED+

REQUEST:
The only way I know to make Queue Depth High alert on lower queue depths when Maximum Queue Depth is set high, is to have IBM make a change to either:
1. Treat Queue Depth High Threshold and Queue Depth Low Threshold values differently when Maximum Queue Depth is set above a certain value or 
2. Accept a decimal point on Queue Depth High Threshold and Queue Depth Low Threshold values