The channel functions available are shown in Table 9. Here some more detail is given about the channel functions.
You can create a new channel definition using the default values supplied by WebSphere MQ, specifying the name of the channel, the type of channel you are creating, the communication method to be used, the transmission queue name and the connection name.
The channel name must be the same at both ends of the channel, and unique within the network. However, you should restrict the characters used to those that are valid for WebSphere MQ object names.
Use the MQSC command ALTER CHANNEL to change an existing channel definition, except for the channel name, or channel type.
Use the MQSC command DELETE CHANNEL to delete a named channel.
Use the MQSC command DISPLAY CHANNEL to display the current definition for the channel.
The MQSC command DISPLAY CHSTATUS displays the status of a channel whether the channel is active or inactive. It applies to all message channels. It does not apply to MQI channels other than server-connection channels on WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp. See Displaying channel status.
Information displayed includes:
Use the MQSC command PING CHANNEL to exchange a fixed data message with the remote end. This gives some confidence to the system supervisor that the link is available and functioning.
Ping does not involve the use of transmission queues and target queues. It uses channel definitions, the related communication link, and the network setup. It can only be used if the channel is not currently active.
It is available from sender and server channels only. The corresponding channel is started at the far side of the link, and performs the startup parameter negotiation. Errors are notified normally.
The result of the message exchange is presented as Ping complete or an error message.
When Ping is invoked, by default no USERID or password flows to the receiving end. If USERID and password are required, they can be created at the initiating end in the channel definition. If a password is entered into the channel definition, it is encrypted by WebSphere MQ before being saved. It is then decrypted before flowing across the conversation.
Use the MQSC command START CHANNEL for sender, server, and requester channels. It should not be necessary where a channel has been set up with queue manager triggering.
Also use the START CHANNEL command for receiver channels that have a disabled status, and on WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, for server-connection channels that have a disabled status. Starting a receiver or server-connection channel that is in disabled status resets the channel and allows it to be started from the remote channel.
When started, the sending MCA reads the channel definition file and opens the transmission queue. A channel start-up sequence is executed, 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 you use triggering or run channels as threads, you will need to start the channel initiator to monitor the initiation queue. Use the runmqchi command for this.
However, TCP and LU 6.2 do provide other capabilities:
Use of the Start option always causes the channel to re-synchronize, where necessary.
For the start to succeed:
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:
\mqm\qmgrs\@SYSTEM\errors\AMQERR01.LOG (for general errors)
MQS_ROOT:[MQM.QMGRS.$SYSTEM.ERRORS]AMQERR01.LOG (for general errors)
<QMVOL>.<SUBVOL>L.MQERRLG1
<MQSVOL>.ZMQSSYS.MQERRLG1
/var/mqm/qmgrs/@SYSTEM/errors/AMQERR01.LOG (for general errors)
Use the MQSC command STOP CHANNEL to request the channel to stop activity. The channel will not start a new batch of messages until the operator starts the channel again. (For information about restarting stopped channels, see Restarting stopped channels.)
This command can be issued to a channel of any type except MQCHT_CLNTCONN.
You can select the type of stop you require:
STOP CHANNEL(QM1.TO.QM2) MODE(QUIESCE)
This command requests the channel to close down in an orderly way. The current batch of messages is completed and the syncpoint procedure is carried out with the other end of the channel.
STOP CHANNEL(QM1.TO.QM2) MODE(FORCE)
This option stops the channel immediately, but does not terminate the channel's thread or process. The channel does not complete processing the current batch of messages, and can, therefore, leave the channel in doubt. In general, it is recommended that operators use the quiesce stop option.
STOP CHANNEL(QM1.TO.QM2) MODE(TERMINATE)
This option stops the channel immediately, and terminates the channel's thread or process.
Use the MQSC command RESET CHANNEL to change the message sequence number. This command is available for any message channel, but not for MQI channels (client-connection or server-connection). The first message starts the new sequence the next time the channel is started.
If the command is issued on a sender or server channel, it informs the other side of the change when the channel is restarted.
Use the MQSC command RESOLVE CHANNEL when messages are held in-doubt by a sender or server, for example because one end of the link has terminated, and there is no prospect of it recovering. The RESOLVE CHANNEL command accepts one of two parameters: BACKOUT or COMMIT. Backout restores messages to the transmission queue, while Commit discards them.
The channel program does not try to establish a session with a partner. Instead, it determines the logical unit of work identifier (LUWID) which represents the in-doubt messages. It then issues, as requested, either:
For the resolution to succeed: