MQSeries for OS/2 Warp configuration

Notes:

1. You can use the sample program AMQSBCG to display, to the stdout spool, 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.

2. The WebSphere MQ command used to start the TCP 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, \mqm\qmgrs\@system\errors, and \mqm\errors. In all 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.

Basic configuration

1. Create the queue manager from the OS/2 command line using the command:

   crtmqm -u dlqname -q os2
   

   where:

   os2

   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, and sets the DEADQ attribute of the queue manager.

2. For SNA channels add an LU 6.2 stanza to the queue manager's qm.ini file:

   LU62:
     TPName=MQSERIES (8)
     LocalLU=OS2QMGR (7)
   

   If you have taken the default options for installation, the qm.ini file for queue manager os2 is found in c:\mqm\qmgrs\os2.

3. Start the queue manager from the OS/2 command line using the command:

   strmqm os2
   

   where os2 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 OS/2 queue manager to implement the channel described in Figure 32. In each case the MQSC command is shown.

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

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 16. Configuration worksheet for MQSeries for OS/2 Warp

MQSeries for OS/2 Warp sender-channel definitions using SNA

def ql (WINNT)                                  (F)
    usage(xmitq) +
    replace
 
def qr (WINNT.REMOTEQ) +                        (D)
    rname(WINNT.LOCALQ) +                       (E)
    rqmname(WINNT) +                            (C)
    xmitq(WINNT) +                              (F)
    replace
 
def chl (OS2.WINNT.SNA) chltype(sdr) +          (G)
    trptype(lu62) +
    conname('NETID.WINNTLU') +                  (13).(15)
    xmitq(WINNT) +                              (F)
    modename('#INTER') +                        (17)
    tpname('MQSERIES') +                        (18)
    replace

MQSeries for OS/2 Warp receiver-channel definitions using SNA

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

MQSeries for OS/2 Warp sender-channel definitions using TCP

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

MQSeries for OS/2 Warp receiver-channel definitions using TCP/IP

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

MQSeries for OS/2 Warp sender-channel definitions using NetBIOS

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

MQSeries for OS/2 Warp receiver-channel definitions using NetBIOS

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

MQSeries for OS/2 Warp sender-channel definitions using IPX/SPX

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

MQSeries for OS/2 Warp receiver-channel definitions using IPX/SPX

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

Running channels as processes or threads

MQSeries for OS/2 Warp provides the flexibility to run sender channels as OS/2 processes or OS/2 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.