Here are some other topics that you should consider when preparing
WebSphere MQ for distributed queue management.
Operator Messages
Because the channel initiator uses a number of asynchronously operating
dispatchers, operator messages could appear on the log out of chronological
sequence.
Channel operation commands
Channel operation commands generally involve two stages. When the command syntax has been checked and the existence of the channel verified, a request is sent to the channel initiator, and message CSQM134I or CSQM137I is sent to the command issuer to indicate the completion of the first stage. When the channel initiator has processed the command, further messages indicating its success or otherwise are send to the command issuer along with message CSQ9022I or CSQ9023I respectively. Any error messages generated could also be sent to the z/OS console.
All cluster commands except DISPLAY CLUSQMGR, however, work asynchronously. Commands that change object attributes update the object and send a request to the channel initiator, and commands for working with clusters are checked for syntax and a request is sent to the channel initiator. In both cases, message CSQM130I is sent to the command issuer indicating that a request has been sent; this is followed by message CSQ9022I to indicate that the command has completed successfully, in that a request has been sent. It does not indicate that the cluster request has completed successfully. The requests sent to the channel initiator are processed asynchronously, along with cluster requests received from other members of the cluster. In some cases, these requests have to be sent to the whole cluster to determine if they are successful or not. Any errors are reported to the z/OS on the system where the channel initiator is running. They are not sent to the command issuer.
A DLQ handler is provided with WebSphere MQ for z/OS. See WebSphere MQ for z/OS System Administration Guide for more information.
MCAs for receiver channels may keep the destination queues open even when messages are not being transmitted; this results in the queues appearing to be 'in use'.
If you change security access for a user ID, the change may not take effect immediately. (See one of WebSphere MQ for z/OS Concepts and Planning Guide, WebSphere MQ for z/OS System Setup Guide and WebSphere MQ for z/OS System Administration Guide for more information.)
If TCP is stopped for some reason and then restarted, the WebSphere MQ for z/OS TCP listener waiting on a TCP port is stopped.
If you are not using the OpenEdition(R) sockets interface, (for example, if you are using the IUCV interface or the Computer Associates SOLVE:TCPaccess interface,) the channel initiator must be stopped and manually restarted when TCP returns. Then, the listener must also be manually restarted to resume communications.
If you are using the OpenEdition sockets interface, automatic channel reconnect allows the channel initiator to detect that TCP/IP is not available and to automatically restart the TCP/IP listener when TCP/IP returns. This alleviates the need for operations staff to notice the problem with TCP/IP and manually restart the listener. While the listener is out of action, the channel initiator can also be used to retry the listener at the interval specified by LSTRTMR in the channel initiator parameter module. These attempts can continue until TCP/IP returns and the listener successfully restarts automatically. For information about LSTRTMR, see the WebSphere MQ for z/OS System Setup Guide.
If APPC is stopped, the listener is also stopped. Again, in this case, the listener automatically retries at the LSTRTMR interval so that, if APPC restarts, the listener can restart too.
If the DB2 fails, shared channels that are already running continue to run, but any new channel start requests will fail. When the DB2 is restored new requests are able to complete.