Starting and Stopping a queue manager from z/OS console - Middleware News

Starting and Stopping a queue manager from z/OS console - Middleware News

Starting a queue manager
=================

You start a queue manager by issuing a START QMGR command. However, you
cannot successfully use the START command unless you have appropriate
authority. See the WebSphere MQ for z/OS System Setup Guide for information
about WebSphere MQ security. Figure 3 shows examples of the START command.
(Remember that you must prefix a WebSphere MQ command with a command
prefix string (CPF).)


+CSQ1 START QMGR
+CSQ1 START QMGR PARM(NEWLOG)

Figure 3. Starting the queue manager from a z/OS console. The second example specifies a system parameter
module name.


See the WebSphere MQ Script (MQSC) Command Reference manual 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
WebSphere 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
should 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(CSQ1MSTR)'

A system parameter module provides information specified when the queue
manager was customized. In Chapter 7, “User messages on startup,” on page 223,
the user message CSQY001I indicates the name of the system parameter module
that was used, in this case, CSQ1ZPRM. For more information about this, see the
WebSphere MQ for z/OS System Setup Guide.

You can also use the ENVPARM option to substitute one or more parameters in
the JCL procedure for the queue manager.

If you then start the your queue manager with the command:

+CSQ1 START QMGR


the CSQINP2 actually 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 that z/OS limits the
KEYWORD=value specifications for symbolic parameters (as in INP2=NEW) to 255
characters.

Starting after an abnormal termination
=============================

WebSphere 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.


Stopping a queue manager
===================

Before stopping a queue manager, all WebSphere MQ-related write-to-operatorwith-
reply (WTOR) messages must receive replies, for example, getting log
requests. Each command in Figure 5 terminates a running queue manager.

+CSQ1 STOP QMGR
+CSQ1 STOP QMGR MODE(QUIESCE)
+CSQ1 STOP QMGR MODE(FORCE)
+CSQ1 STOP QMGR MODE(RESTART)


The command STOP QMGR defaults to STOP QMGR MODE(QUIESCE).

In QUIESCE mode, WebSphere 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 the WebSphere MQ Application Programming Guide 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 WebSphere 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 WebSphere MQ from
ARM. This means that the queue manager is eligible for immediate automatic
restart.

If the WebSphere MQ subsystem is not registered with ARM, the STOP QMGR
MODE(RESTART) command is rejected and the following message is sent to the
z/OS console:

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.

Note: When you stop your queue manager, you might find message IEF352I is
issued. z/OS issues this message if it detects that failing to mark the address space
as unusable would lead to an integrity exposure. You can ignore this message.


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