Starting and stopping a queue manager
Use this topic as an introduction to stopping and starting a queue manager.
Starting and stopping a queue manager is relatively straightforward. When a queue manager stops under normal conditions, its last action is to take a termination checkpoint. This checkpoint, and the logs, give the queue manager the information it needs to restart.
This section contains information about the START and STOP commands, and contains a brief overview of start-up after an abnormal termination has occurred.
Before you start IBM MQ
CSQ3110I +CSQ1 CSQ3UR00 - SUBSYSTEM ssnm INITIALIZATION COMPLETE
where ssnm
is the IBM MQ subsystem name.
From now on, you can start the queue manager for that subsystem from any z/OS console that has been authorized to issue system control commands ; that is, a z/OS SYS command group. You must issue the START command from the authorized console, you cannot issue it through JES or TSO.
If you are using queue-sharing groups, you must start RRS first, and then Db2®, before you start the queue manager.
Starting a queue manager
See START QMGR for information about the syntax of the START QMGR command.
You cannot run the queue manager as a batch job or start it using a z/OS command START. These methods are likely to start an address space for IBM MQ that then ends abnormally. Nor can you start a queue manager from the CSQUTIL utility program or a similar user application.
You can, however, start a queue manager from an APF-authorized program by passing a START QMGR command to the z/OS MGCRE (SVC 34) service.
If you are using queue-sharing groups, the associated Db2 systems and RRS must be active when you start the queue manager.
- Start options
-
When you start a queue manager, a system parameter module is loaded. You can specify the name of the system parameter module in one of two ways:
- With the PARM parameter of the /cpf START QMGR command, for example
/cpf START QMGR PARM(CSQ1ZPRM)
- With a parameter in the startup procedure, for example, code the JCL EXEC statement as
//MQM EXEC PGM=CSQYASCP,PARM='ZPARM(CSQ1ZPRM)'
A system parameter module provides information specified when the queue manager was customized.
You can also use the ENVPARM option to substitute one or more parameters in the JCL procedure for the queue manager.
For example, you can update your queue manager startup procedure, so that the DDname CSQINP2 is a variable. This means that you can change the CSQINP2 DDname without changing the startup procedure. This is useful for implementing changes, providing backouts for operators, and queue manager operations.
Suppose your start-up procedure for queue manager CSQ1 looked like Figure 2.
If you then start your queue manager with the command:+CSQ1 START QMGR
the CSQINP2 used is a member called CSQ1NORM.
However, suppose you are putting a new suite of programs into production so that the next time you start queue manager CSQ1, the CSQINP2 definitions are to be taken from member CSQ1NEW. To do this, you would start the queue manager with this command:+CSQ1 START QMGR ENVPARM('INP2=NEW')
and CSQ1NEW would be used instead of CSQ1NORM. Note: z/OS limits the
KEYWORD=value
specifications for symbolic parameters (as inINP2=NEW
) to 255 characters. - With the PARM parameter of the /cpf START QMGR command, for example
- Starting after an abnormal termination
-
IBM MQ automatically detects whether restart follows a normal shutdown or an abnormal termination.
Starting a queue manager after it ends abnormally is different from starting it after the STOP QMGR command has been issued. After STOP QMGR, 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.
However, if the queue manager ends abnormally, it terminates without being able to finish its work or take a termination checkpoint. When you restart a queue manager after an abend, 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.
- User messages on start-up
-
When you start a queue manager successfully, the queue manager produces a set of startup messages.
Stopping a queue manager
Before stopping a queue manager, all IBM MQ-related write-to-operator-with-reply (WTOR) messages must receive replies, for example, getting log requests. Each command in Figure 3 terminates a running queue manager.
The command STOP QMGR defaults to STOP QMGR MODE(QUIESCE).
In QUIESCE mode, IBM MQ does not allow any new connection threads to be created, but allows existing threads to continue; it terminates only when all threads have ended. Applications can request to be notified in the event of the queue manager quiescing. Therefore, use the QUIESCE mode where possible so that applications that have requested notification have the opportunity to disconnect. See What happens during termination for details.
If the queue manager does not terminate in a reasonable time in response to a STOP QMGR MODE(QUIESCE) command, use the DISPLAY CONN command to determine whether any connection threads exist, and take the necessary steps to terminate the associated applications. If there are no threads, issue a STOP QMGR MODE(FORCE) command.
The STOP QMGR MODE(QUIESCE) and STOP QMGR MODE(FORCE) commands deregister IBM MQ from the MVS Automatic Restart Manager (ARM), preventing ARM from restarting the queue manager automatically. The STOP QMGR MODE(RESTART) command works in the same way as the STOP QMGR MODE(FORCE) command, except that it does not deregister IBM MQ from ARM. This means that the queue manager is eligible for immediate automatic restart.
CSQY205I ARM element arm-element is not registered
If this message is not issued, the queue manager is restarted automatically. For more information about ARM, see Using the z/OS Automatic Restart Manager (ARM).
Only cancel the queue manager address space if STOP QMGR MODE(FORCE) does not terminate the queue manager.
If a queue manager is stopped by either canceling the address space or by using the command STOP QMGR MODE(FORCE), consistency is maintained with connected CICS® or IMS systems. Resynchronization of resources is started when a queue manager restarts and is completed when the connection to the CICS or IMS system is established.
- Stop messages
-
After issuing a STOP QMGR command, you get the messages CSQY009I and CSQY002I, for example:
CSQY009I +CSQ1 ' STOP QMGR' COMMAND ACCEPTED FROM USER(userid), STOP MODE(FORCE) CSQY002I +CSQ1 QUEUE MANAGER STOPPING
Where
userid
is the user ID that issued the STOP QMGR command, and the MODE parameter depends on that specified in the command.When the STOP command has completed successfully, the following messages are displayed on the z/OS console:CSQ9022I +CSQ1 CSQYASCP ' STOP QMGR' NORMAL COMPLETION CSQ3104I +CSQ1 CSQ3EC0X - TERMINATION COMPLETE
If you are using ARM, and you did not specify MODE(RESTART), the following message is also displayed:CSQY204I +CSQ1 ARM DEREGISTER for element arm-element type arm-element-type successful
You cannot restart the queue manager until the following message has been displayed:CSQ3100I +CSQ1 CSQ3EC0X - SUBSYSTEM ssnm READY FOR START COMMAND