Communication between MQ and the filesystem is not direct. MQ will
request a lock of either the active, master, or standby from the OS, the
OS will then communicate this request to the filesystem client, and the
filesystem client will communicate this request to the filesystem server.
.
The response given to this request will be sent back in the reverse order:
.
Request: MQ -> OS -> client -> server
Response: server -> client -> OS -> MQ
.
In the usual case, the active instance will obtain a lock on the active
and master files. The standby instance will obtain a lock on the standby
file.
.
There is a 'lock verify' thread that monitors if the active instance
queue manager maintains access to the files needed for the queue manager
to run. If there is any interruption in accessing these files then the
active instance will release its locks and the standby would request and
gain access to the active file; therefore, now becoming the active instance.
The 'lock verify' thread is monitored by a health check thread to ensure
it is not hung.
.
If a problem is encountered, the details here are commonly seen:
.
http://www-01.ibm.com/support/docview.wss?uid=swg21592501
"AMQ7280 queue manager appears unresponsive, Probeid ZX155001 component zxcFileLockMonitorThread error lrcE_S_Q_MGR_UNRESPONSIVE"
.
It is imperative to ensure the proper requirements are in place:
.
http://www-01.ibm.com/support/docview.wss?uid=swg21433474
"Testing statement for IBM MQ multi-instance queue manager file systems"
.
If NFS is in place then it must be NFSv4:
.
http://www-01.ibm.com/support/docview.wss?uid=swg21681903
"How to verify that the NFS server and NFS client are at version 4"