Remote administration from a local queue manager

This section tells you how to administer a remote queue manager from a local queue manager using MQSC and PCF commands.

Preparing the queues and channels is essentially the same for both MQSC and PCF commands. In this book, the examples show MQSC commands, because they are easier to understand. For more information about writing administration programs using PCF commands, see WebSphere MQ Programmable Command Formats and Administration Interface.

You send MQSC commands to a remote queue manager either interactively or from a text file containing the commands. The remote queue manager might be on the same machine or, more typically, on a different machine. You can remotely administer queue managers in other WebSphere MQ environments, including UNIX systems, Windows systems, OS/400, and z/OS.

To implement remote administration, you must create specific objects. Unless you have specialized requirements, you should find that the default values (for example, for maximum message length) are sufficient.

Preparing queue managers for remote administration

Figure 7 shows the configuration of queue managers and channels that you need for remote administration using the runmqsc command. The object source.queue.manager is the source queue manager from which you can issue MQSC commands and to which the results of these commands (operator messages) are returned. The object target.queue.manager is the name of the target queue manager, which processes the commands and generates any operator messages.

Note:If you are using WebSphere MQ with the -w option, source.queue.manager must be the default queue manager. For further information on creating a queue manager, see crtmqm (create queue manager).

Figure 7. Remote administration using MQSC commands





On both systems, if you have not already done so:

On the target queue manager:

You have to run these commands locally or over a network facility such as Telnet.

Preparing channels and transmission queues for remote administration

To run MQSC commands remotely, set up two channels, one for each direction, and their associated transmission queues. This example assumes that you are using TCP/IP as the transport type and that you know the TCP/IP address involved.

The channel source.to.target is for sending MQSC commands from the source queue manager to the target queue manager. Its sender is at source.queue.manager and its receiver is at target.queue.manager. The channel target.to.source is for returning the output from commands and any operator messages that are generated to the source queue manager. You must also define a transmission queue for each channel. This queue is a local queue that is given the name of the receiving queue manager. The XMITQ name must match the remote queue manager name in order for remote administration to work, unless you are using a queue manager alias. Figure 8 summarizes this configuration.

Figure 8. Setting up channels and queues for remote administration





See WebSphere MQ Intercommunication for more information about setting up channels.

Defining channels and transmission queues

On the source queue manager, issue the following MQSC commands to define the channels and the transmission queue:

  1. Define the sender channel at the source queue manager: 
      DEFINE CHANNEL ('source.to.target') +
         CHLTYPE(SDR) +
         CONNAME (RHX5498) +
         XMITQ ('target.queue.manager') +
         TRPTYPE(TCP)
  2. Define the receiver channel at the source queue manager: 
      DEFINE CHANNEL ('target.to.source') +
         CHLTYPE(RCVR) +
         TRPTYPE(TCP)
  3. Define the transmission queue on the source queue manager: 
      DEFINE QLOCAL ('target.queue.manager') +
         USAGE (XMITQ)

Issue the following commands on the target queue manager (target.queue.manager), to create the channels and the transmission queue there:

  1. Define the sender channel on the target queue manager: 
      DEFINE CHANNEL ('target.to.source') +
         CHLTYPE(SDR) +
         CONNAME (RHX7721) +
         XMITQ ('source.queue.manager') +
         TRPTYPE(TCP)
  2. Define the receiver channel on the target queue manager: 
      DEFINE CHANNEL ('source.to.target') +
         CHLTYPE(RCVR) +
         TRPTYPE(TCP)
  3. Define the transmission queue on the target queue manager: 
      DEFINE QLOCAL ('source.queue.manager') +
         USAGE (XMITQ)
Note:The TCP/IP connection names specified for the CONNAME attribute in the sender channel definitions are for illustration only. This is the network name of the machine at the other end of the connection. Use the values appropriate for your network.

Starting the channels

The way in which you start the channels depends on the environments in which WebSphere MQ is running.

In Windows systems, start a listener as a background process at the receiver end of each channel.

Then start the channels, again as background processes:

On WebSphere MQ for UNIX systems, start a listener at the receiver end of each channel:

Then start the channels as background processes:

The runmqlsr and runmqchl commands are WebSphere MQ control commands. You cannot issue them using runmqsc. You can, however, start channels using runmqsc commands or scripts (start channel).

Automatic definition of channels

If WebSphere MQ receives an inbound attach request and cannot find an appropriate receiver or server-connection definition in the channel definition file (CDF), it creates a definition automatically and adds it to the CDF. Automatic definitions are based on two default definitions supplied with WebSphere MQ: SYSTEM.AUTO.RECEIVER and SYSTEM.AUTO.SVRCONN.

You enable automatic definition of receiver and server-connection definitions by updating the queue manager object using the MQSC command, ALTER QMGR (or the PCF command Change Queue Manager).

For more information about creating channel definitions automatically, see WebSphere MQ Intercommunication. For information about automatically defining channels for clusters, see WebSphere MQ Queue Manager Clusters.

Managing the command server for remote administration

Each queue manager can have a command server associated with it. A command server processes any incoming commands from remote queue managers, or PCF commands from applications. It presents the commands to the queue manager for processing and returns a completion code or operator message depending on the origin of the command.

A command server is mandatory for all administration involving PCF commands, the MQAI, and also for remote administration.

Note:For remote administration, ensure that the target queue manager is running. Otherwise, the messages containing commands cannot leave the queue manager from which they are issued. Instead, these messages are queued in the local transmission queue that serves the remote queue manager. Avoid this situation.

There are separate control commands for starting and stopping the command server. Users of WebSphere MQ for Windows can perform the operations described in the following sections using the WebSphere MQ Services snap-in. For more information, see Chapter 8, "Administration using the WebSphere MQ Services snap-in".

Starting the command server

To start the command server, use the command: 

strmqcsv saturn.queue.manager

where saturn.queue.manager is the queue manager for which the command server is being started.

Displaying the status of the command server

For remote administration, ensure that the command server on the target queue manager is running. If it is not running, remote commands cannot be processed. Any messages containing commands are queued in the target queue manager's command queue.

To display the status of the command server for a queue manager called saturn.queue.manager, the command is: 

dspmqcsv saturn.queue.manager

You must issue this command on the target machine. If the command server is running, the following message is returned: 

AMQ8027    WebSphere MQ Command Server Status ..: Running

Stopping a command server

To end the command server started by the previous example use the following command: 

endmqcsv saturn.queue.manager

You can stop the command server in two ways:

Note:Stopping a queue manager also ends the command server associated with it.

Issuing MQSC commands on a remote queue manager

The command server must be running on the target queue manager, if it is going to process MQSC commands remotely. (This is not necessary on the source queue manager.)

This form of the runmqsc command, with the -w flag, runs the MQSC commands in indirect mode, where commands are put (in a modified form) on the command-server input queue and executed in order.

When you type in an MQSC command, it is redirected to the remote queue manager, in this case, target.queue.manager. The timeout is set to 30 seconds; if a reply is not received within 30 seconds, the following message is generated on the local (source) queue manager: 

AMQ8416: MQSC timed out waiting for a response from the command server.

When you stop issuing MQSC commands, the local queue manager displays any timed-out responses that have arrived and discards any further responses.

In indirect mode, you can also run an MQSC command file on a remote queue manager. For example: 

runmqsc -w 60 target.queue.manager < mycomds.in > report.out

where mycomds.in is a file containing MQSC commands and report.out is the report file.

Working with queue managers on z/OS

You can issue MQSC commands to a z/OS queue manager from a queue manager on the platforms described in this book. However, to do this, you must modify the runmqsc command and the channel definitions at the sender.

In particular, you add the -x flag to the runmqsc command on the source node to specify that the target queue manager is running under z/OS: 

runmqsc -w 30 -x target.queue.manager

Recommendations for issuing commands remotely

When you are issuing commands on a remote queue manager:

  1. Put the MQSC commands to be run on the remote system in a command file.
  2. Verify your MQSC commands locally, by specifying the -v flag on the runmqsc command.

    You cannot use runmqsc to verify MQSC commands on another queue manager.

  3. Check that the command file runs locally without error.
  4. Run the command file against the remote system.

If you have problems using MQSC commands remotely

If you have difficulty in running MQSC commands remotely, make sure that you have:

See also Resolving problems with MQSC commands.


© IBM Corporation 1994, 2002. All Rights Reserved