To change the locking behaviour similar to MQv9.1 and to support both MQv9.2 & MQv9.1 behaviour, with an option for the user to choose.

An option in say qm.ini, so that both OLD, MQv9.1 & NEW, MQv9.2 onwards behaviour for acquiring the file system by the standby instance, are supported, especially since the option that appears to have been utilised in MQv9.2 is specified by Storage provider as 'an optional feature and clients should not depend on its presence.'

Also certainly since we know that the MQv9.1 code retries continuously every 2 secs, and this works for us.

#############################################################################

IBM MQ Support mentioned following;

We have a difference between MQ 9.1 and MQ 9.2 on how the standby instance acquires lock. 
In MQ 9.1 the standby instance attempts to acquire the lock using try lock function and if the lock is not available the fcntl system call returns and then the standby instance retry the lock request every 2 seconds. 
In case of MQ 9.2 the standby instance issues lock request and it waits for the lock and the thread does not return from fcntl call until fcntl call fails with an error
or fcntl call acquired the lock. I suspect the problem is likely on the file system causing delay in the locking. 

##############################################################################

We utilise the Storage provider DELL Unity Storage for MQ 9.2 under Multi-Instance, DELL Unity do not have the option implemented as it is an optional RFC item.

The IBM support ticket has all the information documented in detail TS010830905 and is preventing us from migrating to MQv9.2, also MQv9.1 will be unsupported from September 2023.

Mahesh from L3 support was in a meeting held today between SITA, IBM & DELL, and suggested that we raise this RFE as a priority item, was also suggested by MQ Support as in the ticket.