Hay 10 clases de personas: las que saben binario y las que no.
Linking | TroubleShooting | Shut Dummies | Re-Connect (v7) RFHUTILC | URLs | End

MQ Client

Intro

Per accedir (remotament) a un MQ i no tenir el MQ (ni instalat ni pagat ni configurat), ens cal el "MQ Client". Compte : cal pagar el manteniment, i el "Client Attachment Feature" del z/OS no es de franc.

Després de instalar-lo (sols 16,5 MB), per verificar que funciona, - fent servir els objectes del sistema (mètode no gaire recomanat) -, hem de fer :

Es a dir, del MQ Servidor ens cal :

Per fer

SET MQSERVER=VMSCC/TCP/9.136.0.149(1433) AMQSPUTC VMRXQ VMQM AMQSGBRC VMRXQ VMQM

Una altra descripció : [url]

There are two requirements that must be completed before you can configure the client/server communication.
First, you must define a server connection channel on the queue manager that will provide support to the client. A channel is a definition that enables intercommunication between queue managers, or between clients and queue managers.
Second, the MQ Client must be installed and configured on the client, which might or might not be on the same machine as the server. Use the MQSERVER environment variable to define the client connection to the server.

The following code is an example of how to set this variable in Windows operating environments:

set MQSERVER=ChannelName/TransportType/ConnectionName(port) As : set MQSERVER=SERVER.CHANNEL1/TCP/1.2.3.4(1414)

Introduction to MQ Clients - url

RedBook "WebSephere MQ V6 Fundamentals"

En la tabla 7-1 "Summary of how a client MCA chooses client connection channel objects" del capitulo 7.3.5 "Client connection channel objects" explica que existe la posibilidad de definir canales cliente con el nombre del gestor destino a blanco o con un * como comodín.
XA and MQ Cli

Estudiar la participació del MQ Client en transaccions locals/globals.

The Extended Transactional Client allows a WMQ Client to participate in two-phase transactions.

Linking C applications with the MQ client code

Having written your MQ application that you want to run on the MQ client, you must link it to a queue manager. You can do this in two ways:

  1. Directly, in which case the queue manager must be on the same machine as your application
  2. To a client library file, which gives you access to queue managers on the same or on a different machine.

    Win : MQIC32.DLL

    Linux : libmqic.so library for non-threaded applications, or libmqic_r.so library for threaded applications.

MQ v 5.3, "Clients" page158 [172/206] ; url.

Per programar-lo cal fer servir aquestes llibreries :
In MQ for Windows, you must link your program to the MQI library files supplied for the environment in which you are running your application, in addition to those provided by the operating system:

#include <cmqc.h> /* For regular MQI definitions */ MQM.LIB 48.164 Server for 32-bit C MQIC.LIB Client for 16-bit C MQIC32.LIB 48.402 Client for 32-bit C IMQ*.LIB Server for C++ MQMXA.LIB Static XA interface for C MQMENC.LIB Dynamic XA interface in C for Encina MQMTUX.LIB Dynamic XA interface in C for Tuxedo Alper : IMQC23VN.lib - client IMQS23VN.lib - server
Compilació Linux

Fem servir :

#!/bin/bash fn="MQget.c" echo "Compilem ("$fn") per MQ Server:" cc -L/usr/mqm/lib -lmqm -o MQget $fn echo "Compilem ("$fn") per MQ Client:" cc -L/usr/mqm/lib -lmqic -o MQgetc $fn
Maneres de conectarse al servidor

If the MQSERVER environment variable is set, a MQ client uses the client-connection channel definition specified by MQSERVER in preference to any definitions in the client channel definition table.
The MQSERVER environment variable takes priority over any client channel definition pointed to by MQCHLLIB and MQCHLTAB.

Setting MQSERVER overrides the MQCHLLIB/MQCHLTAB env vars.

Seqüencia per conectarse al servidor

When an application running in an WebSphere MQ client environment issues an MQCONN or MQCONNX call, the client identifies how it is to make the connection. When an MQCONNX call is issued by an application on a WebSphere MQ client, the MQI client library searches for the client channel information in the following order:

  1. Using the contents of the ClientConnOffset or ClientConnPtr fields of the MQCNO structure (if supplied). These identify the channel definition structure (MQCD) to be used as the definition of the client connection channel.
  2. If the MQSERVER environment variable is set, the channel it defines is used.
  3. If the MQCHLLIB and MQCHLTAB environment variables are set, the client channel definition table they point to is used.
  4. Finally, if the environment variables are not set, the client searches for a client channel definition table whose path and name are established from the DefaultPrefix in the mqs.ini file or the Registry for Windows(R). If this fails, the client uses the following paths:
    • UNIX(R) systems : /var/mqm/AMQCLCHL.TAB
    • Windows : C:\Program Files\IBM\Websphere MQ\amqclchl.tab

The first of the options described above (using the ClientConnOffset or ClientConnPtr fields of MQCNO) is supported only by the MQCONNX call. If the application is using MQCONN rather than MQCONNX, the channel information is searched for in the remaining three ways in the order shown above. If the client fails to find any of these, the MQCONN or MQCONNX call fails.

The channel name (for the client connection) must match the server-connection channel name defined on the server for the MQCONN or MQCONNX call to succeed.

url

Examples of MQCONN calls

url

Client Channel Definition Table = CCDT

CCDT definition : MQ v 6.0 Fundamentals, 7.3.6, page 166 [190/446]

Each client connection channel object that is defined adds an entry to a file called the client channel definition table (CCDT) individual to that queue manager. The client channel definition table can contain more than one client-connection channel definition.

On the client machine, you can then use the environment variables, MQCHLLIB and MQCHLTAB, to specify the location and name of the file containing the client channel definition table.

[Unix] export MQCHLLIB=/mqmtop/qmgrs/QUEUEMANAGERNAME/@ipcc export MQCHLTAB=AMQCLCHL.TAB

AMQCLCHL.TAB is a binary file that cannot be edited directly. It is automatically generated when a client connection channel is created in MQ. This table contains a list of client channels for the Queue Manager. Configuration information of each client channel and its associated server channel, listener port, and the WebSphere MQ server host name, is stored in the table.

You can use the DEFINE CHANNEL command to add a client connection channel to the table, and the ALTER CHANNEL command to alter the attributes of a channel that already has an entry in the table.

Do not delete AMQCLCHL.TAB. It contains default channel definitions that are required when you define a channel. If you suspect that this has been deleted, for example you get error messages when you try to define a new channel, check to see that the file exists.

url

Location :

Perl access - implementation details "the channel table is basically a doubly linked list of MQCDs", etc

When is AMQCLCHL.TAB created ?
Where is AMQCLCHL.TAB created ?

If you do not find AMQCLCHL.TAB in the place it was suposed to be, mind MQCHLLIB and MQCHLTAB envir vars :

The client channel table will be created in the location these variables are referencing.

url

How to display AMQCLCHL.TAB contents ?
Client Connection Channel

MQ client queue-manager groups:
If the specified name starts with an asterisk (*), the queue manager to which connection is made might have a different name from that specified by the application. The specified name (without the asterisk) defines a group of queue managers that are eligible for connection. The implementation selects one from the group by trying each one in turn (in no defined order) until one is found to which a connection can be made. If none of the queue managers in the group is available for connection, the call fails. Each queue manager is tried once only. If an asterisk alone is specified for the name, an implementation-defined default queue-manager group is used.

url

Client Connection Channel

In "WebSephere MQ V6 Fundamentals" Redbook, table 7-1 of chapter "7.3.5 Client connection channel objects", it says you can request a connection to a Queue Manager name set to blank or starting with * as "wild card" part of the name.

Com posar un asterisk en el nom del QMGR requerit : Example 3. Queue manager name is blank or an asterisk (*), from "Clients" + "Application Programming".
Using the wildcard in MQCONN !

HA sample for MQ Clients

Highly available gateway into our MQ infrastructure for MQ client applications without using a HA software like VCS.

The gateway consists of two queue managers on two different servers, say QMGR_A and QMGR_B on server A and B respectively. QMGR_A will act as the primary gateway queue manager. Should QMGR_A become unavailable, QMGR_B should provide connectivity into the MQ network.

Channels were defined as follows:

On QMGR_A, server A

DEF CHANNEL(FDPD.SVRCONN.A) CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('myuser') DEF CHANNEL(FDPD.SVRCONN.A) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME('A.B.C.D(10000)') DEF CHANNEL(FDPD.SVRCONN.B) CHLTYPE(CLNTCONN) TRPTYPE(TCP) CONNAME('E.F.G.H(10000)')

On QMGR_B, server B

DEF CHANNEL(FDPD.SVRCONN.B) CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('myuser')

The TAB file from QMGR_A on server A is then located on the application machines where it is pointed to by the MQCHLLIB & MQCHLTAB env variable. The MQSERVER variable is left un-set.

Upon starting the client application, connection is achieved to QMGR_A, exactly as expected. When QMGR_A is shut down, connection is made to QMGR_B. That's why it is important not to specify the queue manager name in the channel definitions. Nor is it necessary to specify the queue manager name in the application code. MQ decides which queue manager to connect to based on the channel definitions.

Acces points split

Each Client can have a diferent table.

In that table it will try connecting alphabetically by channel name assuming the channels and MQCONN call have a blank QM name specified.

So :

  1. QM name := " " ;
  2. "Client-1*" table :
    DEF CHANNEL(CONN.A) CHLTYPE(CLNTCONN) CONNAME('1.1.1.1(1415)') DEF CHANNEL(CONN.B) CHLTYPE(CLNTCONN) CONNAME('2.2.2.2(1416)') DEF CHANNEL(CONN.C) CHLTYPE(CLNTCONN) CONNAME('3.3.3.3(1417)')
  3. "Client-2*" table :
    DEF CHANNEL(CONN.F) CHLTYPE(CLNTCONN) CONNAME('1.1.1.1(1415)') DEF CHANNEL(CONN.D) CHLTYPE(CLNTCONN) CONNAME('2.2.2.2(1416)') DEF CHANNEL(CONN.E) CHLTYPE(CLNTCONN) CONNAME('3.3.3.3(1417)')
  4. "Client-3*" table :
    DEF CHANNEL(CONN.H) CHLTYPE(CLNTCONN) CONNAME('1.1.1.1(1415)') DEF CHANNEL(CONN.I) CHLTYPE(CLNTCONN) CONNAME('2.2.2.2(1416)') DEF CHANNEL(CONN.G) CHLTYPE(CLNTCONN) CONNAME('3.3.3.3(1417)')

So, client-1 will try IP "1", then IP "2", then IP "3". Client-2 shall try IP "2" first, then "3", then "1". Client-3 shall try IP "3" first, then "1", then "2".

This means, each Server's shall have the following correponding definitions :

  1. Server-1 [ ip = '1.1.1.1' ] :
    DEF CHANNEL(CONN.A) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.F) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.H) CHLTYPE(SVRCONN)
  2. Server-2 [ ip = '2.2.2.2' ] :
    DEF CHANNEL(CONN.B) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.D) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.I) CHLTYPE(SVRCONN)
  3. Server-3 [ ip = '3.3.3.3' ] :
    DEF CHANNEL(CONN.C) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.E) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.G) CHLTYPE(SVRCONN)

And, finally, the complete definitions are :

  1. Server-1, generating the table to be distributed among "Client-1*" :
    DEF CHANNEL(CONN.A) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.F) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.H) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.A) CHLTYPE(CLNTCONN) CONNAME('1.1.1.1(1415)') DEF CHANNEL(CONN.B) CHLTYPE(CLNTCONN) CONNAME('2.2.2.2(1416)') DEF CHANNEL(CONN.C) CHLTYPE(CLNTCONN) CONNAME('3.3.3.3(1417)')
  2. Server-2, generating the table to be distributed among "Client-2*" :
    DEF CHANNEL(CONN.B) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.D) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.I) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.F) CHLTYPE(CLNTCONN) CONNAME('1.1.1.1(1415)') DEF CHANNEL(CONN.D) CHLTYPE(CLNTCONN) CONNAME('2.2.2.2(1416)') DEF CHANNEL(CONN.E) CHLTYPE(CLNTCONN) CONNAME('3.3.3.3(1417)')
  3. Server-3, generating the table to be distributed among "Client-3*" :
    DEF CHANNEL(CONN.C) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.E) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.G) CHLTYPE(SVRCONN) DEF CHANNEL(CONN.H) CHLTYPE(CLNTCONN) CONNAME('1.1.1.1(1415)') DEF CHANNEL(CONN.I) CHLTYPE(CLNTCONN) CONNAME('2.2.2.2(1416)') DEF CHANNEL(CONN.G) CHLTYPE(CLNTCONN) CONNAME('3.3.3.3(1417)')
CCDT and WAS

In WAS we have set the JMS properties as follows:

JMS Connection Factory: Queue Manager: [blank] Channel: [blank] Custom Property: CCDTURL: file:///www/iaf/mq_ccdt/CHL1.TAB QMANAGER: * JMS Queue: Queue Manager: [blank] Channel: [blank]

2 preguntes : (a) com s'escull al codi JMS si la conexio es a un servidor local o es una conexio client a un servidor remot ? (b) com es defineixen els parametres de MQ al WAS ?

Configuring a unified JMS connection factory for the default messaging provider url

Generic JMS connection factory settings url

Using a client channel definition table from a JMS client application

For example, if the file ccdt1.tab contains a client channel definition table and is stored on the same system on which the application is running, the application can set the CCDTURL property in the following way:

java.net.URL chanTab1 = new URL("file:///home/admdata/ccdt1.tab"); factory.setCCDTURL(chanTab1);

As another example, suppose the file ccdt2.tab contains a client channel definition table and is stored on a system that is different to the one on which the application is running. If the file can be accessed using the FTP protocol, the application can set the CCDTURL property in the following way:

java.net.URL chanTab2 = new URL("ftp://ftp.server/admdata/ccdt2.tab"); factory.setCCDTURL(chanTab2);

Publib url

Using the MQCNO structure on an MQCONNX call

A MQ client application can use the connect options structure, MQCNO, on an MQCONNX call to reference a channel definition structure, MQCD, that contains the definition of a client-connection channel. In this way, the client application can specify the ChannelName, TransportType, and ConnectionName attributes of a channel at run time, and this enables the client application to connect to multiple server queue managers simultaneously. This is not possible if you define a channel using the MQSERVER environment variable.

MQ 5.3, "Clients", GC34-6058-01, page 132 [146/206].

url, url.

Compte per als Clients de versió 6 : set MQCD_CURRENT_VERSION := '8' ;

url

Load-balancing routers

If we have a bounch of MQ Clients trying to access a cluster of MQ Servers (and over-imposed MB's) the entry point is a SPOF (Single Pont Of Failure).

Maybe we can use a "clever load-balancer" to distribute the workload over the MQ Server Pool ...

Triggering (client)

Messages sent by MQ applications running on MQ clients contribute to triggering in exactly the same way as any other messages, and they can be used to trigger programs on the server. The trigger monitor and the application to be started must both be on the same system.

MQ 6.0, "Clients", chapter 12 'Triggerring in the client environment', GC34-6590-01, page 118 [134/169] or url

Process definition (client)

You must define the process definition on the server, because this is associated with the queue that has triggering set on. The process object defines what is to be triggered. If the client and server are not running on the same platform, any processes started by the trigger monitor must define ApplType.

Trigger monitor (client)
The trigger monitor provided by non-z/OS MQ products runs in the client environments. To run the trigger monitor, issue the command:

runmqtmc [-m QMgrName] [-q InitQ]

The default initiation queue is SYSTEM.DEFAULT.INITIATION.QUEUE on the default queue manager. This is where the trigger monitor looks for trigger messages. It then calls programs for the appropriate trigger messages. This trigger monitor supports the default application type and is the same as runmqtrm except that it links the client libraries.
The command string, built by the trigger monitor, is as follows:

  1. The ApplicId from the relevant process definition. This is the name of the program to run, as it would be entered on the command line.
  2. The MQTMC2 structure, enclosed in quotes, as got from the initiation queue. A command string is invoked that has this string, exactly as provided, in quotes in order that the system command will accept it as one parameter.
    • 1 QName
    • 2 ProcessName
    • 3 TriggerData
    • 4 ApplType
    • 5 UserData
    • 6 QMgrName
  3. The EnvrData from the relevant process definition.

MQ 5.3, "Clients", chapter 12 'Triggerring in the client environment', GC34-6058-01, page 157 [171/206].

MA7K provides a trigger monitor (TM) which runs as a Windows service and is linked with the MQ client library (mqic32).

Schema
Client | Server (1.2.3.4) ------------------------------------------ | ------------------------------------- | | Queue Manager Name := "QMN(1490)" ; RUNMQTMC -m QMN -q INIT_Q | | Data Queue Name := "DATA_Q" ; | Init Queue Name := "INIT_Q" ; SET MQSERVER=MY.SVRCONN/TCP/1.2.3.4(1490) | | Process Definition := "wr2fi.exe" ; | MY.SVRCONN ------------------------ O O ------------------------ |

[1]

DEFINE QLOCAL (INIT_Q) + LIKE (SYSTEM.DEFAULT.LOCAL.QUEUE) + DESCR ('initiation queue description') + REPLACE DEFINE PROCESS (CTP) + DESCR ('Client Trigger Process') + APPLTYPE (WINDOWSNT) + APPLICID ('c:\temp\wr2fi.exe') + USERDATA ('ctp User Data') + ENVRDATA ('ctp Env Data') + REPLACE DEFINE QLOCAL (DATA_Q) + LIKE (SYSTEM.DEFAULT.LOCAL.QUEUE) + DESCR ('appl queue description') + INITQ ('INIT_Q') + PROCESS ('CTP') + TRIGGER + TRIGTYPE (FIRST) + // as "wr2fi" does not remove messages from queue, change it to "every" REPLACE

[2]

T42:\MQ\Triggering> type engega_trigger_monitor.cmd SET MQSERVER=MY.SVRCONN/TCP/1.2.3.4(1490) RUNMQTMC -m QMN -q INIT_Q

[3]

T42:\MQ\Triggering> type posa_missatge.cmd SET MQSERVER=MY.SVRCONN/TCP/1.2.3.4(1490) AMQSPUTC DATA_Q QMN < texte_missatge.txt

[4] - wr2fi.exe writes file ZZZ.TXT in the directory where [2] was issued !

If you get
AMQ8605 Queue manager not available to the WebSphere MQ trigger monitor
verify AMQERR01.LOG for connectivity problems.

Error messages with MQ clients

When an error occurs with a MQ client system, error messages are put into the error files associated with the server, if possible. If the error cannot be placed there, the MQ client attempts to place the error message in an error log in the root directory of the MQ client machine.

Exclusive use of a SVRCONN channel
Capitalware - MQ Authenticate User Security Exit (499 USD), MQ Standard Security Exit (249 USD)
Machines without "C:" drive

The MQ client has an (unexpected) hardcoded drive letter in it, so machines without a C drive are in trouble.
Error 1327 "Invalid Drive c:" right after responding ENGLISH on the language panel.

MQCNO @ MQCONNX

You can use the MQCONNX call to specify a channel definition (MQCD) structure in the MQCNO structure. This allows the calling client application to specify the definition of the client-connection channel at run-time.

Max number of connections and/or MQConn() delay

If you intend to run a high number of concurrent connections to MQ, we recommend that you increase the number of kernel timers, or CALLOUTS as they are known. You configure the number of CALLOUTs available using the NCALLOUT kernel parameter. By default, NCALLOUT is equal to (16 + NPROC), where NPROC is the total number of processes allowed on the system. As WebSphere MQ is threaded, you could choose a value similar to (16 + NKTHREAD). However, there is an overhead in kernel memory for every CALLOUT defined, so tune this value to the requirements of the individual system.

MQ v 6.0 for HP-UX quick beginnings, page 14 [28/79], GC34-6479-01.

You can use MQINQ to retrieve the maximum handles for the queue manager. Max Handles defines the maximum number of tasks (?) that a specific task can open with a queue manager.
You can know about the current (dynamic) connections made to the QM by using

runmqsc <qmname> 5 : display qmstatus all AMQ8705: Display Queue Manager Status Details. QMNAME(MQDES01) STATUS(RUNNING) CONNS(629) CMDSERV(RUNNING) CHINIT(RUNNING)

Definition : CRTMQM -h <num>

Actual value : DISPLAY QMGR + MAXHANDS(*)
MAXHANDS refers to the maximum number of objects that a single connection can have open at the same time.

url

MQCONNX number and Delphi @ Indi
\\T400\Delphi\IMI_MB_Monitor { hace 1 conexion } + \\T400\Delphi\MultiThreading\BuscarLimitThreads { arranca N threads } => \\T400\MQ\Eines\AMQSCNXC_proves_Conexio_Client\IMI_Buscar_Max_Conexiones { N conexiones, "client esgotador" }

Delphi code "client esgotador".

AMQ9513: Maximum number of channels reached.

Edit qm.ini file for that queue manager:

Channels: MaxChannels=nn MaxActiveChannels=nn

Guindous :

url

Límits :

Display how many Connections do we have right now
echo "DISPLAY CHSTATUS(MY.SVRCONN)" | runmqsc MY_QM | grep -c "CHLTYPE(SVRCONN)"
Limitar el número de conexiones cliente (mq v7)
MAXINST The maximum number of simultaneous instances of an individual server-connection channel that can be started. MAXINSTC The maximum number of simultaneous individual server-connection channels that can be started from a single client. In this context, connections that originate from the same remote network address are regarded as coming from the same client. BACKLOG The number of concurrent connection requests that the listener supports.

I would expect to look at different client = different conname. However I would expect each instance of the same client to count towards MAXINST.

So let's look at it

MAXCHANNELS total of channels (include all types) MAXACTIVECHANNELS total of active channels (includes all types)

SVRCONN only

MAXINST total of instances accross all clients (conname) of a specific channel MAXINSTC total of instances for a specific channel for a specific client (conname)

So MAXINST is the limit at "destination" side of the SVRCONN tube, and MAXINSTC is the limit at "origin" side of the SVRCONN tube.

v7 improvements

A client program can request connection to a queue manager name that is prefixed by an asterisk (*). This directs MQ to attempt connection using an alphabetic list of CLNTCONN type channels defined in a Client Channel Definition Table (CCDT) file. New parameters have been added to the CLNTCONN channel definition to allow random selection based on a relative weighting and availability of queue managers.

2 : display CHANNEL(SYSTEM.DEF.CLNTCONN) CHLTYPE(CLNTCONN) all AMQ8414: Display Channel details. CHANNEL(SYSTEM.DEF.CLNTCONN) CHLTYPE(CLNTCONN) AFFINITY(PREFERRED) ALTDATE(2009-01-12) ALTTIME(00.47.00) CLNTWGHT(0) COMPHDR(NONE) COMPMSG(NONE) CONNAME( ) DESCR( ) HBINT(300) KAINT(AUTO) LOCLADDR( ) MAXMSGL(4194304) MODENAME( ) PASSWORD( ) QMNAME( ) RCVDATA( ) RCVEXIT( ) SCYDATA( ) SCYEXIT( ) SENDDATA( ) SENDEXIT( ) SHARECNV(10) SSLCIPH( ) SSLPEER( ) TPNAME( ) TRPTYPE(TCP) USERID( )

CLNTWGHT :
The client channel weighting attribute is used so client channel definitions can be selected at random based on their weighting when more than one suitable definition is available. Specify a value in the range 0 - 99. The default is the special value 0. The special value 0 indicates that no random load balancing is performed and applicable definitions are selected in alphabetical order. To enable random load balancing the value should be in the range 1 through 99 where 1 is the lowest weighting and 99 is the highest. When a client issues an MQCONN with queue manager name ?*<name>? and more than one suitable definition is available in the CCDT the choice of definition to use is randomly selected based on the weighting with any applicable CLNTWGHT(0) definitions selected first in alphabetical order. The distribution is not guaranteed.

AFFINITY :
PREFERRED
The first connection in a process reading a CCDT creates a list of applicable definitions based on the weighting with any applicable CLNTWGHT(0) definitions first and in alphabetical order. Each connection in the process attempts to connect using the first definition in the list.

SVRCONN parameters
DEFINE CHANNEL(channel-name) CHLTYPE(SVRCONN) TRPTYPE(TCP) COMPHDR . COMPMSG . DESCR . DISCINT . HBINT . KAINT . LIKE . MAXINST (v7) MAXINSTC (v7) MAXMSGL 4194304 | 104857600 MCAUSER . MONCHL . NOREPLACE REPLACE QSGDISP . RCVDATA . RCVEXIT . SCYDATA . SCYEXIT . SENDDATA . SENDEXIT . SSLCAUTH . SSLCIPH . SSLPEER .
CLNTCONN parameters
DEFINE CHANNEL(channel-name) CHLTYPE(CLNTCONN) TRPTYPE(TCP) AFFINITY (PREFERRED) ALTDATE (2009-01-12) ALTTIME (00.47.00) CLNTWGHT (0) COMPHDR (NONE) COMPMSG (NONE) CONNAME ( ) DESCR ( ) HBINT (300) KAINT (AUTO) LOCLADDR ( ) MAXMSGL (4194304) MODENAME ( ) PASSWORD ( ) QMNAME ( ) ???????? RCVDATA( ) RCVEXIT( ) SCYDATA( ) SCYEXIT( ) SENDDATA( ) SENDEXIT( ) SHARECNV(10) SSLCIPH( ) SSLPEER( ) TPNAME( ) TRPTYPE(TCP) USERID( )
SVRCONN/CLNTCONN channel
display channel(CONN.A) 2 : display channel(CONN.A) AMQ8414: Display Channel details. CHANNEL(CONN.A) CHLTYPE(SVRCONN) ALTDATE(2009-02-26) ALTTIME(23.41.36) COMPHDR(NONE) COMPMSG(NONE) DESCR( ) HBINT(300) KAINT(AUTO) MAXINST(999999999) MAXINSTC(999999999) MAXMSGL(4194304) MCAUSER( ) MONCHL(QMGR) RCVDATA( ) RCVEXIT( ) SCYDATA( ) SCYEXIT( ) SENDDATA( ) SENDEXIT( ) SHARECNV(10) SSLCAUTH(REQUIRED) SSLCIPH( ) SSLPEER( ) TRPTYPE(TCP) AMQ8414: Display Channel details. CHANNEL(CONN.A) CHLTYPE(CLNTCONN) AFFINITY(PREFERRED) ALTDATE(2009-02-26) ALTTIME(23.41.36) CLNTWGHT(0) COMPHDR(NONE) COMPMSG(NONE) CONNAME(9.137.164.15(1421)) DESCR( ) HBINT(300) KAINT(AUTO) LOCLADDR( ) MAXMSGL(4194304) MODENAME( ) PASSWORD( ) QMNAME( ) RCVDATA( ) RCVEXIT( ) SCYDATA( ) SCYEXIT( ) SENDDATA( ) SENDEXIT( ) SHARECNV(10) SSLCIPH( ) SSLPEER( ) TPNAME( ) TRPTYPE(TCP) USERID( )
Amunt! Top Amunt!
MQ Client + MQCHLTAB demo
Amunt! Top Amunt!
Client troubleshooting
Amunt! Top Amunt!
Dummy clients shutdown
Amunt! Top Amunt!
5.7 Weighted selection on CLNTCONN channels

In recent versions of WebSphere MQ a client program can request connection to a queue manager name that is prefixed by an asterisk (*): MQCONN( "*SALES", &hConn, &CompCode, &ReasCode );

This feature is demonstrated in the section "Examples of using MQCONN calls" of the manual WebSphere MQ Clients, which is available in the WebSphere MQ V7.0 Information Center at: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp

The asterisk instructs MQ to attempt connection using a set of channel names that are defined in a Client Channel Definition Table. The algorithm builds an alphabetic list of channel names that match the queue manager name. It then attempts to connect using the first channel in the list. If this does not succeed it tries the next one, and so on.

The typical application of this simple algorithm is to provide a secondary backup queue manager that is used when the primary queue manager is not available. New parameters have been added to the CLNTCONN-type channel in WebSphere MQ V7.0 to allow more intelligent selection based on a relative weighting and availability of queue managers. Simple selection by alphabetic precedence and random selection based on a numeric weighting factor are both provided. This extends the algorithm to cater for workload balancing across multiple queue managers.

MQ V7.0 Features and Enhancements redbook, chapter 5.

MQ Client v7 Reconnect

MQ clients can take advantage of automatic reconnection if their connection to a queue manager is broken. To make this common procedure easier, a client program can connect to a queue manager with the option of being automatically reconnected to another queue manager (or reconnected to this queue manager) if the current connection fails.

Should no longer see: MQRC_CONNECTION_BROKEN (MQRC 2009)

Automatic reconnection can be enabled administratively with a new parameter of the channels stanza in the mqclient.ini file. The DefRecon parameter has several settings and can perform the following tasks:

url : Use the CONNECTIONNAMELIST and CLIENTRECONNECTOPTIONS properties of the MQClientConnectionFactory class to configure a client connection to automatically reconnect following a connection failure.

Automatic client reconnect is not supported by WebSphere MQ classes for Java.

Location of the client configuration file, mqclient.ini

A client application uses the following search path to locate the WebSphere MQ client configuration file:

  1. The location specified by the environment variable MQCLNTCF.
  2. A file called mqclient.ini in the present working directory of the application.
  3. A file called mqclient.ini in the WebSphere MQ data directory for UNIX systems or installation directory for Windows.

url

CHANNELS stanza of the client configuration file
DefRecon=NO|YES|QMGR|DISABLED NO Unless overridden by MQCONNX, the client is not reconnected automatically. YES Unless overridden by MQCONNX, the client reconnects automatically. QMGR Unless overridden by MQCONNX, the client reconnects automatically, but only to the same queue manager. The QMGR option has the same effect as MQCNO_RECONNECT_Q_MGR. DISABLED Reconnection is disabled, even if requested by the client program using the MQCONNX MQI call.
CHANNELS: ChannelDefinitionDirectory=value ChannelDefinitionFile=value DefRecon=value MQReconnectTimeout=value XAReconnectTimeout=value

url

By default the client application will look for the mqclient.ini file in the path from which it is executing, so specifically tailored .ini files can be provided for each and every client.

Automatic client reconnection

You can make your client applications reconnect automatically, without writing any additional code, by configuring a number of components.
Auto-reconnection is inline, that is, the connection is automatically restored at any point in the client application program, and the handles to open objects are all restored.

By default clients are not automatically reconnected. Automatic reconnection is enabled by setting the MQCONNX MQCNO Option MQCNO_RECONNECT or MQCNO_RECONNECT_Q_MGR
Many applications are written in such a way that they are able to take advantage of auto-reconnection with no additional coding. You can enable automatic reconnection for existing programs, without making any coding changes, by setting the DefRecon attribute in the channels stanza of the mqclient.ini configuration file.

url

Options (MQLONG) - Options that control the action of MQCONNX.
Reconnection options : MQCNO_RECONNECT_AS_DEF, MQCNO_RECONNECT, MQCNO_RECONNECT_DISABLED or MQCNO_RECONNECT_Q_MGR.

url

White paper "Exploiting the Automatic Client Reconnect feature introduced in WebSphere MQ 7.0.1 – MQI (C Code)" : url.

Amunt! Top Amunt!
RFHUTILC

Params : USER.OWN.SVRCONN/TCP/1.2.3.4(1415)

Amunt! Top Amunt!
MQ Client URLs
Actualitzat el 20/10/2011.