Home
Channel definition commands
The DEFINE CHANNEL, ALTER CHANNEL, and DISPLAY CHANNEL commands have two specific CHLTYPE parameters for clusters: CLUSRCVR and CLUSSDR. To define a cluster-receiver channel you use the DEFINE CHANNEL command, specifying CHLTYPE(CLUSRCVR). Many of the other attributes needed on a cluster-receiver channel definition are the same as those that apply to a receiver channel or a sender channel definition. To define a cluster-sender channel you use the DEFINE CHANNEL command, specifying CHLTYPE(CLUSSDR), and many of the same attributes as you use to define a sender channel.
It is no longer necessary to specify the full repository queue manager's name when you define a cluster-sender channel. So long as you know the naming convention used for channels in your cluster we can make a CLUSSDR definition using the +QMNAME+ construction (+QMNAME+ is not supported on z/OS). After connection WebSphere MQ changes the name of the channel and substitutes the correct full repository queue manager name in place of +QMNAME+. The resulting channel name is truncated to 20 characters.
Clearly this works only if your convention for naming channels includes the name of the queue manager. For example, if you have a full repository queue manager called QM1 with a cluster-receiver channel called TO.QM1.ALPHA, another queue manager can define a cluster-sender channel to this queue manager, but specify the channel name as TO.+QMNAME+.ALPHA.
If you use the same naming convention for all your channels, be aware that only one +QMNAME+ definition can exist at one time.
The attributes on the DEFINE CHANNEL and ALTER CHANNEL commands that are specific to cluster channels are:
Use the CLUSTER attribute to specify the name of the cluster with which this channel is associated. Alternatively, use the CLUSNL attribute to specify a namelist of cluster names.
Use the NETPRTY attribute to specify a network priority for the channel. This helps the workload management routines. If there is more than one possible route to a destination, the workload management routine selects the one with the highest priority.
Use the CLWLPRTY parameter to apply a priority factor to channels to the same destination for workload management purposes. This parameter specifies the priority of the channel for the purposes of cluster workload distribution. The value must be in the range zero through 9, where zero is the lowest priority and 9 is the highest.
Use the CLWLRANK parameter to apply a ranking factor to a channel for workload management purposes. This parameter specifies the rank of a channel for the purposes of cluster workload distribution. The value must be in the range zero through 9, where zero is the lowest rank and 9 is the highest.
Use the CLWLWGHT parameter to apply a weighting factor to a channel for workload management purposes. This parameter weights the channel so that the proportion of messages sent down that channel can be controlled. The cluster workload algorithm uses the channel's weight attribute to bias the destination choice so that more messages can be sent over a particular channel. By default all channel weight attributes are the same default value. The weight attribute allows you to allocate a channel on a powerful UNIX machine a larger weight than another channel on small desktop PC. This means the cluster workload algorithm selects the UNIX machine more frequently than the PC as the destination for messages.
These attributes on the DEFINE CHANNEL command and ALTER CHANNEL command also apply to the DISPLAY CHANNEL command.
The CONNAME specified on a cluster-receiver channel definition is used throughout the cluster to identify the network address of the queue manager. Take care to select a value for the CONNAME parameter that resolves throughout your WebSphere MQ cluster. Do not use a generic name. Remember that the value specified on the cluster-receiver channel takes precedence over any value specified in a corresponding cluster-sender channel.
The following paragraphs discuss the facility to omit the CONNAME value on a CLUSRCVR definition. This is not possible on z/OS.
When the network protocol you are using is TCP/IP it is not necessary to specify the network address of your queue manager when you define a cluster-receiver channel. We can issue the DEFINE CHANNEL command without supplying a value for CONNAME. WebSphere MQ generates a CONNAME for you, assuming the default port and using the current IP address of the system. The generated CONNAME is always in the dotted-decimal (IPv4) or hexadecimal (IPv6) form, rather than in the form of an alphanumeric DNS host name.
This facility is useful when you have machines using Dynamic Host Configuration Protocol (DHCP). With WebSphere MQ if you do not supply a value for the CONNAME on a CLUSRCVR channel, you do not need to make any changes to your definitions if DHCP allocates you a new IP address.
If you specify a blank for the CONNAME on the CLUSRCVR definition, WebSphere MQ generates a CONNAME from the IP address of the system. Only the generated CONNAME is stored in the repositories. Other queue managers in the cluster do not know that the CONNAME was originally blank.
If you issue the DISPLAY CLUSQMGR command you will see the generated CONNAME. However, if you issue the DISPLAY CHANNEL command from the local queue manager, you will see that the CONNAME is blank.
If the queue manager is stopped and restarted with a different IP address, because of DHCP, WebSphere MQ regenerates the CONNAME and updates the repositories accordingly.
Auto-defined cluster-sender channels take their attributes from those specified in the corresponding cluster-receiver channel definition on the receiving queue manager. Even if there is a manually-defined cluster-sender channel, its attributes are automatically modified to ensure that they match those on the corresponding cluster-receiver definition. Beware that we can, for example, define a CLUSRCVR without specifying a port number in the CONNAME parameter, whilst manually defining a CLUSSDR that does specify a port number. When the auto-defined CLUSSDR replaces the manually defined one, the port number (taken from the CLUSRCVR) becomes blank. The default port number would be used and the channel would fail.
Note that the DISPLAY CHANNEL command does not display auto-defined channels. However, we can use the DISPLAY CLUSQMGR command, introduced in DISPLAY CLUSQMGR , to examine the attributes of auto-defined cluster-sender channels.
Use the DISPLAY CHSTATUS command to display the status of a cluster-sender or cluster-receiver channel. This command gives the status of both manually defined channels and auto-defined channels.
For full details of the attributes and syntax of the DEFINE CHANNEL, ALTER CHANNEL, DISPLAY CHANNEL, and DISPLAY CHSTATUS commands, refer to the WebSphere MQ Script (MQSC) Command Reference book.
The equivalent PCFs are MQCMD_CHANGE_CHANNEL, MQCMD_COPY_CHANNEL, MQCMD_CREATE_CHANNEL, and MQCMD_INQUIRE_CHANNEL. For information about these PCFs, refer to the WebSphere MQ Programmable Command Formats and Administration Interface book.
Parent topic:
MQSC command attributes
qc11130_
Home