On June 9, 2011 IBM released Fixpack 1 of the Q Replication Dashboard v10.1.  Cool new features include an Alert Manager that sends e-mail messages when replication thresholds are breached (e.g. end-to-end latency exceeds 30 seconds).  After some tire-kicking, I will let you know if this is a viable substitute for the asnmon monitoring feature of Q Replication.  The dashboard has also been integrated with Tivoli Enterprise Portal.

Full details and the free download are at https://www-304.ibm.com/support/docview.wss?rs=3557&uid=swg24023065&wv=1

Here is another technique to use only when standard practices won’t work.  Let’s say you are performing a manual load in Q Replication (either InfoSphere Replication Server or DB2 Homogeneous Replication Feature).  Ordinarily you would INSERT a LOADDONE into the IBMQREP_SIGNAL table.  The INSERT into the Q Replication Control Table is logged and Q Capture will see it.

BUT, what if Q Capture is way behind?  Various operational problems could cause this.  The manual load has actually completed, but the WebSphere MQ spill queues are growing because Q Apply doesn’t know that.  It might take hours for Q Capture to get to the point in the log where the LOADDONE is posted.

Here are the steps to bypass LOADDONE and initiate the draining of the spill queues by Q Apply:

1. Stop Q Capture.
2. Wait for the Receive queue to empty.  The reason for this is that Q Capture sets an indicator in the message placed on the Send queue specifying that a subscription is still being manually loaded.
3. Stop Q Apply.
4. For each subscription where the LOAD has completed: change the STATE value in the IBMQREP_TARGETS table from ‘E’ to ‘F’ and change the STATE value in the IBMQREP_SUBS table from ‘L’ to ‘A’.
5. Start Q Apply.
6. Start Q Capture.

Thanks to Christian Zentgraf and Anupama Mahajan of IBM and my TFG colleague, Jim Herrmann, for developing this procedure.