Remote administration from a local queue manager

 

---

Overview

This section tells you how to administer a remote queue manager from a local queue manager using MQSC commands. Preparing the queues and channels is essentially the same for both MQSC and PCF commands.

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, create specific objects. Unless you have specialized requirements, find that the default values (for example, for maximum message length) are sufficient.

On both systems, you need to:

• Create the queue manager and the default objects, using the crtmqm command.

• Start the queue manager, using the strmqm command.

On the target queue manager:

• The command queue, SYSTEM.ADMIN.COMMAND.QUEUE, must be present. This queue is created by default when a queue manager is created.

• Start the command server, using the strmqcsv command.

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

 

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.

 

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)
   

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

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

• On the source queue manager, type:

  runmqlsr -t TCP -m source.queue.manager
  

• On the target queue manager, type:

  runmqlsr -t TCP -m target.queue.manager
  

Then start the channels as background processes:

• On the source queue manager, type:

  runmqchl -c source.to.target -m source.queue.manager &
  

• On the target queue manager, type:

  runmqchl -c target.to.source -m source.queue.manager &
  

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

 

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.

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.

 

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:

• For a controlled stop, use the endmqcsv command with the -c flag, which is the default.

• For an immediate stop, use the endmqcsv command with the -i flag.

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

• On the target queue manager, type:

  strmqcsv target.queue.manager
  

• On the source queue manager, you can then run MQSC commands interactively in indirect mode by typing:

  runmqsc -w 30 target.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, 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:

• Started the command server on the target queue manager.

• Defined a valid transmission queue.

• Defined the two ends of the message channels for both:

  • The channel along which the commands are being sent.

  • The channel along which the replies are to be returned.

• Specified the correct connection name (CONNAME) in the channel definition.

• Started the listeners before you started the message channels.

• Checked that the disconnect interval has not expired, for example, if a channel started but then shut down after some time. This is especially important if you start the channels manually.

• Sent requests from a source queue manager that do not make sense to the target queue manager (for example, requests that include parameters that are not supported on the remote queue manager).

See also Resolving problems with MQSC commands.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.