We often give the advice that MQ CF structures should be backed up regularly, by which we mean at least every hour. A recent customer problem that I dealt with showed why this is good advice.


MQ application CF structures are used to hold shared queues. As is the case with private queues, queue managers write information to their logs whenever they put or get a persistent message to a shared queue.

A backup of a CF structure can be taken by issuing the BACKUP CFSTRUCT command on one queue manager in the QSG. This writes the current contents of the structure to the log of the queue manager performing the backup.

In some situations, the contents of a CF structure can be lost. This could be due to a problem such as loss of power to the CF, or it could be that the QSG is being started at different site, such as in a DR situation.

In this case the persistent messages on the structure can be recovered by issuing the RECOVER CFSTRUCT command on any queue manager in the QSG (this can also be done automatically by MQ if RECAUTO(YES) has been set on the CFSTRUCT definition). To recover the structure the queue manager must read the logs of all the queue managers in the QSG that used the structure, going back to the last time a backup of the structure was taken. This can take a few minutes on a system with a high volume of persistent messaging, even if the CF structure was backed up recently. Queues on the structure won’t be available until the recovery has completed.

What if there’s no backup?

If the CF structure hasn’t been backed up for a long time, or even never backed up, the queue manager will need to go very far back in the logs of all the queue managers in the QSG to recover the structure. If you’re lucky, this will take a long time, and will almost certainly mean reading archive logs, which could be on tape. The queue manager will issue message CSQE133I periodically to show the progress of the recovery.

If you’re unlucky, the archive logs needed to recover the structure will have been deleted, and there will be no way to recover the persistent messages on the structure. In this case, the only option is likely to be to issue the RECOVER CFSTRUCT TYPE(PURGE) command. This will make the structure available once again for applications to use, but all messages on the structure will have been lost.


In short, make sure you back up your CF structures regularly!

The queue manager periodically checks whether a backup has been taken of CF structures recently and issues messages CSQ040I or CSQE041E if this is not the case, so it might be worth monitoring for these messages.

3 comments on"What happens if you don’t back up your CF structures?"

  1. Hi,

    Thanks a million for the quick reply. Yes, it answers my query.

    Thanks again,

  2. Hi,

    I have a query-so once the backup is taken, there will be lots of persistent messages which are part of successful transaction(after the backup was taken),these should not be recovered when RECOVER CFSTRUCT is performed.How is this taken care by the queue manager.


    • gwydiontudur January 23, 2018


      Any puts and gets of persistent messages that are committed after the backup was taken will be recorded in the log of the queue manager that performed the transaction. This is why the queue manager recovering the structure needs to read through the logs of all the queue managers in the QSG, so it knows about all the changes have been made since the backup was taken.

      For example, a persistent message that exists in the backup, but has since been successfully got, will not be recovered because the get will have been logged by a queue manager in the QSG.

      Hope that answers your question.

Join The Discussion

Your email address will not be published.