WebSphere MQ for Windows configuration

Notes:

1. You can use the sample program, AMQSBCG, to display the contents and headers of all the messages in a queue. For example:

   AMQSBCG q_name qmgr_name
   

   displays the contents of the queue q_name defined in queue manager qmgr_name.

   Alternatively, you can use the message browser in the WebSphere MQ Explorer.

2. The WebSphere MQ command used to start the TCP/IP listener is:

   runmqlsr -t tcp
   

   The listener enables receiver channels to start automatically in response to a start request from an inbound sender channel.

3. You can start any channel from the command prompt using the command

   runmqchl -c channel.name
   

4. Error logs can be found in the directories \mqm\qmgrs\qmgrname\errors and \mqm\qmgrs\@system\errors. In both cases, the most recent messages are at the end of amqerr01.log.

5. When you are using the command interpreter runmqsc to enter administration commands, a + at the end of a line indicates that the next line is a continuation. Ensure that there is a space between the last parameter and the continuation character.

Default configuration

You can create a default configuration by using either the First Steps application or the WebSphere MQ Postcard application to guide you through the process. For information about this, see the WebSphere MQ System Administration Guide book.

Basic configuration

You can create and start a queue manager from the WebSphere MQ Explorer or from the command prompt.

If you choose the command prompt:

1. Create the queue manager using the command:

   crtmqm -u dlqname -q winnt
   

   where:

   winnt

   Is the name of the queue manager

   -q

   Indicates that this is to become the default queue manager

   -u dlqname

   Specifies the name of the undeliverable message queue

   This command creates a queue manager and a set of default objects.

2. Start the queue manager using the command:

   strmqm winnt
   

   where winnt is the name given to the queue manager when it was created.

Channel configuration

The following sections detail the configuration to be performed on the Windows queue manager to implement the channel described in Figure 32.

In each case the MQSC command is shown. Either start runmqsc from a command prompt and enter each command in turn, or build the commands into a command file.

Examples are given for connecting WebSphere MQ for Windows and MQSeries for OS/2 Warp. If you wish to connect to another WebSphere MQ product use the appropriate set of values from the table in place of those for OS/2.

Note:

The words in bold are user-specified and reflect the names of WebSphere MQ objects used throughout these examples. If you change the names used here, ensure that you also change the other references made to these objects throughout this book. All others are keywords and should be entered as shown.

Table 18. Configuration worksheet for WebSphere MQ for Windows

WebSphere MQ for Windows sender-channel definitions using SNA

def ql (OS2) +                                  (F)
    usage(xmitq) +
    replace
 
def qr (OS2.REMOTEQ) +                          (D)
    rname(OS2.LOCALQ) +                         (E)
    rqmname(OS2) +                              (C)
    xmitq(OS2) +                                (F)
    replace
 
def chl (WINNT.OS2.SNA) chltype(sdr) +          (G)
    trptype(lu62) +
    conname(OS2CPIC) +                          (18)
    xmitq(OS2) +                                (F)
    replace

WebSphere MQ for Windows receiver-channel definitions using SNA

def ql (WINNT.LOCALQ) replace                   (B)
 
def chl (OS2.WINNT.SNA) chltype(rcvr) +         (I)
    trptype(lu62) +
    replace

WebSphere MQ for Windows sender-channel definitions using TCP/IP

def ql (OS2) +                                  (F)
    usage(xmitq) +
    replace
 
def qr (OS2.REMOTEQ) +                          (D)
    rname(OS2.LOCALQ) +                         (E)
    rqmname(OS2) +                              (C)
    xmitq(OS2) +                                (F)
    replace
 
def chl (WINNT.OS2.TCP) chltype(sdr) +          (H)
    trptype(tcp) +
    conname(remote_tcpip_hostname) +
    xmitq(OS2) +                                (F)
    replace

WebSphere MQ for Windows receiver-channel definitions using TCP

def ql (WINNT.LOCALQ) replace                   (B)
 
def chl (OS2.WINNT.TCP) chltype(rcvr) +         (J)
    trptype(tcp) +
    replace

WebSphere MQ for Windows sender-channel definitions using NetBIOS

def ql (OS2) +                                  (F)
    usage(xmitq) +
    replace
 
def qr (OS2.REMOTEQ) +                          (D)
    rname(OS2.LOCALQ) +                         (E)
    rqmname(OS2) +                              (C)
    xmitq(OS2) +                                (F)
    replace
 
def chl (WINNT.OS2.NET) chltype(sdr) +          (K)
    trptype(netbios) +
    conname(remote_system_NetBIOS_name) +
    xmitq(OS2) +                                (F)
    replace

WebSphere MQ for Windows receiver-channel definitions using NetBIOS

def ql (WINNT.LOCALQ) replace                   (B)
 
def chl (OS2.WINNT.NET) chltype(rcvr) +         (M)
    trptype(tcp) +
    replace

WebSphere MQ for Windows sender-channel definitions using SPX

def ql (OS2) +                                  (F)
    usage(xmitq) +
    replace
 
def qr (OS2.REMOTEQ) +                          (D)
    rname(OS2.LOCALQ) +                         (E)
    rqmname(OS2) +                              (C)
    xmitq(OS2) +                                (F)
    replace
 
def chl (WINNT.OS2.SPX) chltype(sdr) +          (L)
    trptype(spx) +
    conname('network.node(socket)') +
    xmitq(OS2) +                                (F)
    replace

WebSphere MQ for Windows receiver-channel definitions using SPX

def ql (WINNT.LOCALQ) replace                   (B)
 
def chl (OS2.WINNT.SPX) chltype(rcvr) +         (N)
    trptype(tcp) +
    replace

Automatic startup

WebSphere MQ for Windows allows you to automate the startup of a queue manager and its channel initiator, channels, listeners, and command servers. Use the IBM WebSphere MQ Services snap-in to define the services for the queue manager. When you have successfully completed testing of your communications setup, set the relevant services to automatic within the snap-in. This file can be read by the supplied WebSphere MQ service when the system is started.

For more information about this, see the WebSphere MQ System Administration Guide book.

Running channels as processes or threads

WebSphere MQ for Windows provides the flexibility to run sender channels as Windows NT processes or Windows NT threads. This is specified in the MCATYPE parameter on the sender channel definition. Each installation should select the type appropriate for their application and configuration. Factors affecting this choice are discussed below.

Most installations will select to run their sender channels as threads, because the virtual and real memory required to support a large number of concurrent channel connections will be reduced. When the WebSphere MQ listener process (started via the RUNMQLSR command) exhausts the available private memory needed, an additional listener process will need to be started to support more channel connections. When each channel runs as a process, additional processes are automatically started, avoiding the out-of-memory condition.

If all channels are run as threads under one WebSphere MQ listener, a failure of the listener for any reason will cause all channel connections to be temporarily lost. This can be prevented by balancing the threaded channel connections across two or more listener processes, thus enabling other connections to keep running. If each sender channel is run as a separate process, the failure of the listener for that process will affect only that specific channel connection.

A NetBIOS connection needs a separate process for the Message Channel Agent. Therefore, before you can issue a START CHANNEL command, you must start the channel initiator, or you may start a channel using the RUNMQCHL command.

Multiple thread support -- pipelining

Consider a message exit that opens a queue and uses its handle for MQPUT calls on all subsequent invocations of the exit. This fails in pipelining mode because the exit is called from different threads. To avoid this failure, keep a queue handle for each thread and check the thread identifier each time the exit is invoked.