Starting a channel

Use the MQSC command START CHANNEL for sender, server, and requester channels. For applications to be able to exchange messages, we must start a listener program for inbound connections.

START CHANNEL is not necessary where a channel has been set up with queue manager triggering.

When started, the sending MCA reads the channel definitions and opens the transmission queue. A channel start-up sequence is issued, which remotely starts the corresponding MCA of the receiver or server channel. When they have been started, the sender and server processes await messages arriving on the transmission queue and transmit them as they arrive.

When we use triggering or run channels as threads, ensure that the channel initiator is available to monitor the initiation queue. The channel initiator is started by default as part of the queue manager.

However, TCP and LU 6.2 do provide other capabilities:

• For TCP on UNIX and Linux, inetd can be configured to start a channel. inetd is started as a separate process.
• For LU 6.2 in UNIX and Linux, configure your SNA product to start the LU 6.2 responder process.
• For LU 6.2 in Windows, using SNA Server we can use TpStart (a utility provided with SNA Server) to start a channel. TpStart is started as a separate process.

Use of the Start option always causes the channel to resynchronize, where necessary.

For the start to succeed:

• Channel definitions, local and remote, must exist. If there is no appropriate channel definition for a receiver or server-connection channel, a default one is created automatically if the channel is auto-defined. See Channel auto-definition exit program.
• Transmission queue must exist, and have no other channels using it.
• MCAs, local and remote, must exist.
• Communication link must be available.
• Queue managers must be running, local and remote.
• Message channel must not be already running.

A message is returned to the screen confirming that the request to start a channel has been accepted. For confirmation that the start command has succeeded, check the error log, or use DISPLAY CHSTATUS. The error logs are:

Windows

MQ_INSTALLATION_PATH\qmgrs\qmname\errors\AMQERR01.LOG (for each queue manager called qmname)

MQ_INSTALLATION_PATH\qmgrs\@SYSTEM\errors\AMQERR01.LOG (for general errors)

MQ_INSTALLATION_PATH represents the high-level directory in which IBM MQ is installed.

Note: On Windows, you still also get a message in the Windows systems application event log.

UNIX and Linux

/var/mqm/qmgrs/qmname/errors/AMQERR01.LOG (for each queue manager called qmname)

/var/mqm/qmgrs/@SYSTEM/errors/AMQERR01.LOG (for general errors)

On UNIX, Linux, and Windows, use the runmqlsr command to start the IBM MQ listener process. By default, any inbound requests for channel attachment causes the listener process to start MCAs as threads of the amqrmppa process.

runmqlsr -t tcp -m QM2

For outbound connections, we must start the channel in one of the following three ways:

1. Use the MQSC command START CHANNEL, specifying the channel name, to start the channel as a process or a thread, depending on the MCATYPE parameter. (If channels are started as threads, they are threads of a channel initiator.)

   START CHANNEL(QM1.TO.QM2)
   

2. Use the control command runmqchl to start the channel as a process.

   runmqchl -c QM1.TO.QM2 -m QM1
   

3. Use the channel initiator to trigger the channel.

Parent topic: Getting started with objects