Data queues
Data queue objects can replicate the definition only, or both the definition and the contents of standard (*STD) type data queues. Distributed data management (*DDM) and display (*DSP) type data queues are not eligible for replication.
Data queue entries are, by default, disabled for replication. Before enabling data queue entry replication, it is recommended that Adding and removing data queue entries be reviewed. To establish data queue entries as eligible for replication, refer to Object replication controls.
Updates made directly to a data queue using the Enqueue (ENQ) and Dequeue (DEQ) Machine Interface (MI) instructions are not replicated.
Restoring replicated data queues
A replicated data queue cannot be restored over an existing data queue with the same name. To restore a data queue that already exists, you must either first delete the existing data queue, or restore the data queue to another library. Before deleting a replicated data queue, use ALCOBJ with a lock state of *EXCL to ensure that the data queue is not in use on either node of the Db2® Mirror pair.
Locking considerations for data queues
No object lock is held on the data queue while waiting for messages with the Receive Data Queue (QRCVDTAQ) API. Therefore, it is important to check both the source and the target nodes of the Db2 Mirror pair to make sure the data queue is not in use before deleting the data queue.
Resynchronization of data queues
When the replication state is TRACKING and any change is made to a replicated data queue, the *DTAQ object will be saved and restored to the secondary node when replication is resumed.
Since restore processing cannot restore over an existing data queue, resynchronization processing will first delete the existing data queue on the secondary, and then proceed with the restore.
If applications were waiting on a receive of a data queue entry on the secondary, the resynchronization processing will cause the receive to fail with escape message CPF9805 or SQLCODE -443 with SQLSTATE'42704'.