Restarting IBM MQ
After a queue manager terminates there are different restart procedures needed depending on how the queue manager terminated. Use this topic to understand the different restart procedures that you can use.
Restarting after a normal shutdown
If the queue manager was stopped with the STOP QMGR command, the system finishes its work in an orderly way and takes a termination checkpoint before stopping. When you restart the queue manager, it uses information from the system checkpoint and recovery log to determine the system status at shutdown.
To restart the queue manager, issue the START QMGR command as described in Starting and stopping a queue manager.
Restarting after an abnormal termination
IBM® MQ automatically detects whether restart follows a normal shutdown or an abnormal termination.
Starting the queue manager after it has terminated abnormally is different from starting it after the STOP QMGR command has been issued. If the queue manager terminates abnormally, it terminates without being able to finish its work or take a termination checkpoint.
To restart the queue manager, issue the START QMGR command as described in Starting and stopping a queue manager. When you restart a queue manager after an abnormal termination, it refreshes its knowledge of its status at termination using information in the log, and notifies you of the status of various tasks.
Normally, the restart process resolves all inconsistent states. But, in some cases, you must take specific steps to resolve inconsistencies. This is described in Recovering units of work manually.
Restarting if you have lost your page sets
If you have lost your page sets, you need to restore them from your backup copies before you can restart the queue manager. This is described in How to back up and recover page sets.
The queue manager might take a long time to restart under these circumstances because of the length of time needed for media recovery.
Restarting if you have lost your log data sets
If, after stopping a queue manager (using the STOP QMGR command), both copies of the log are lost or damaged, you can restart the queue manager providing you have a consistent set of page sets (produced using Method 1: Full backup ).
- Define new page sets to correspond to each existing page set in your queue manager. See Task 15: Define your page sets for information about page set definition.
Ensure that each new page set is larger than the corresponding source page set.
- Use the FORMAT function of CSQUTIL to format the destination page set. See Formatting page sets for more details.
- Use the RESETPAGE function of CSQUTIL to copy the existing page sets or reset them in place, and reset the log RBA in each page. See Copying a page set and resetting the log for more information about this function.
- Redefine your queue manager log data sets and BSDS using CSQJU003 (see The change log inventory utility ).
- Restart the queue manager using the new page sets. To do this, you do one of the following:
- Change the queue manager started task procedure to reference the new page sets. See Task 6: Create procedures for the IBM MQ queue manager for more information.
- Use Access Method Services to delete the old page sets and then rename the new page sets, giving them the same names as the old page sets.
If the queue manager is a member of a queue-sharing group, GROUP and SHARED object definitions are not normally affected by lost or damaged logs. However, if any shared-queue messages are involved in a unit of work that was covered by the lost or damaged logs, the effect on such uncommitted messages is unpredictable.
Restarting if you have lost your CF structures
You do not need to restart if you lose your CF structures, because the queue manager does not terminate.