MQ Client

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 és de franc. Also, Extended Transactional (XA) Clients are not free.

The advantages of using a client architecture is that there is no requirement to have servers defined and managed on all the outlying machines.

The disadvantage is that if the network is down for any reason the applications will not be able to connect to the servers and do any messaging. It should also be noted that messaging in a client applications is generally slower than in a locally connected application.

TMM34 - MQ clients

Power of MQI vs Portability of JMS

The MQI is particular to WebSphere MQ and while it is extremely common and powerful it is not provided by any other messaging provider.

JMS is the standard way of doing messaging in a Java environment and, as such, applications written to JMS should port easily to another provider. Note, however, than a JMS application on one provider can not necessarily communicate with a JMS application on another provider.

MQ Client is often used to verify a remote queue manager has been installed properly.

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 :

• definir un canal de tipus SVRCON :
  DEFINE CHANNEL('SEBAS.SVRCONN') CHLTYPE(SVRCONN) + MCAUSER('no_user') + REPLACE

  El canal tiene que estar definido en el Gestor de colas del servidor MQ como tipo Server Connection [ACR, 19/05/2005] Otherwise (o canal inactivo), se recibe un "rc = 2059".
  Además, en este canal debe definirse un MCA User Id que pertenezca al grupo mqm - otherwise, se obtiene un "rc = 2035".

• definir la variable de entorn MQSERVER=Canal/Protocol/IP(Port)
  SET MQSERVER=MY.SVRCONN/TCP/my_ip(1414) = canal/protocol/IP(MQ server port) ECHO %MQSERVER%

• usar "AMQSPUTC SYSTEM.DEFAULT.LOCAL.QUEUE" para poner en la cola
• usar "AMQSBCGC SYSTEM.DEFAULT.LOCAL.QUEUE" para mirar en la cola
• usar "AMQSGETC SYSTEM.DEFAULT.LOCAL.QUEUE" para leer (y borrar) de la cola

Es a dir, del MQ Servidor ens cal :

• Server Connection Channel name (VMSCC) [amb MCA User ID inclòs a "mqm"]
• IP (9.136.0.149 - vmWare SAVE at T30)
• listener port (1433 at QMgr "VMQM")
• receive queue name (VMRXQ)
• queue manager name (VMQM)

Per fer

Una altra descripció : [url]

Introduction to MQ Clients - url

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

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

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 (and 'AMQZSAIC.DLL' - use depends.exe)

   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:

Fem servir :

• MQ_Conn_X() - té un parametre més per posar la IP i el port
• MQ_Conn() - fa servir la variable d'entorn MQSERVER
• MQCHLTAB - es copia el fitxer AMQCLCHL.TAB del Servidor al Client i s'hi apunta amb dues variables d'entorn.

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.

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

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].

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

url

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.

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 :

• Unix : /mqmtop/qmgrs/QUEUEMANAGERNAME/@ipcc
• Windows : C:\Program Files\IBM\WebSphere MQ\qmgrs\QUEUEMANAGERNAME\@ipcc

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

• crtmqm
• runmqsc qmgrname < input.cfg
• runmqsc + DEFINE/ALTER CHANNEL command, with CHLTYPE(CLNTCONN)
• CHLTYPE(CLNTCONN) is what updates AMQCLCHL.TAB
• Client Table is created/updated when you create CLNTCONN channel definitions.
• when you use runmqsc to DEFINE or ALTER a CLNTCONN channel, as well as the information in the clntconn directory being updated the channel table file pointed to by MQCHLLIB and MQCHLTAB (or the default values if those environment variables are not specified) is also updated with the new definition.

  url

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

• Copy the AMQCLCHL.TAB to /var/mqm/qmgrs/TestQMgrName/@ipcc directory.
  Issue the runmqsc TestQMgrName command, then DIS CHL(*) CHLTYPE(CLNTCONN) ALL and you'll see what's really in the TAB file.

• MO72 - use MO72 support pack to edit the CCDT ... MO72 is a great product that allows a user to create a CCDT file without requiring MQ to be installed on that server.

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

We generate a OFV.TAB with these definitions:

And we can use it from JMS :

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 !

In WAS we have set the JMS properties as follows:

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

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:

Publib

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 ...

• F5 BigIP (maja)
• GSS from Cisco (hilltops)

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

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.

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).

• [1] create objects in QMN (server)
• [2] start trigger monitor client (client)
• [3] put a message (wherever)
• [4] verify

[1]

[2]

[3]

[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.

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.

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.

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

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

Delphi code "client esgotador".

Edit qm.ini file for that queue manager:

Guindous :

• Select MQSeries Explorer from Start, Programs, IBM MQSeries.
• Select your queue manager.
• Go to the Actions menu and select Properties.
• Select the Channels tab.
• Enter a value in the MaxChannels and MaxActiveChannels field that is greater than 100 (100 is the default value)

url

Límits :

• max handles -> MQRC_MAX_CONNS_LIMIT_REACHED
  (2025, X'7E9') Maximum number of connections reached

• max channels - see qm.ini V6 - propiedades del Qmgr.

  Win2003Server :

  reg add \HKLM\SOFTWARE\IBM\MQSeries\CurrentVersion\Configuration\QueueManager\qmgr_name\CHANNELS /v MaxChannels /t REG_SZ /d 32767

Linux :

Guindous (sense cometes al ECHO i amb FIND):

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

SVRCONN only

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

Maybe we have a bad client who is using too much host resources.

And we get

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.

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.

So, to have a "random" selection of channels in CCDT, we shall code

Top

• create a CCDT with 2 qmgrs in it, SALE and SALE_BACKUP
• use modified amqscnxc to send MQ_Inq() and display actual queue manager name
• code is in \\MQ\Eines\AMQSCNXC_proves_Conexio_Client\

• create cluster with 6 qmgr's : FR1, FR2, ENT1, ENT2, MB1, MB2, with CCDT to ENT1 and ENT2 (T430:\\GN\scripts)
• get AMQCLCHL.TAB and set MQCHLLIB and MQCHLTAB
• use AMQSPUTC ENTRADA * < dades.txt to write into the "entrada" cluster queue using high availability

Top

• is the listener running ?
• is the listener running on the port you expect it to ?
• are you using the right channel ?
• telnet hostname port does still not return the blank screen:
  do you have a firewall that is blocking the port or the protocol ?
• is it an ip4 Vs ip6 problem ?
• can you client connect ?
• client connect is working but not bindings mode for a local qmgr:
  Do you have <MQInstall>/java/lib and <MQInstall/bin> on the lib path and path?
• what does the qmgr's log say ? Any trace of your connection attempts ?
• client access : verify the user has the proper authorizations
• client triggering : verify the trigger monitor is running : runmqtmc.exe
• If your (MQ Client) Application code has problems connecting to a remote (or local) queue manager, use amqscnxc sample code to determine if it is application or configuration problem ! (same MQSERVER / CCDT)

Top

Envir :

• T430, W7, MQ v 7.5
• qm(QM_CNT), port(1955), channel(SAG.SVRCONN), queue(QL.IN)
• SAG.SVRCONN has to have "Sharing Conversations=1"

Top

• heartbeat interval - HBINT(300)
• KeepAlive interval - KAINT(AUTO) - applies to SVRCONN channels on the mainframe only.
• tell the developer that even if the application receives an exception, issue a disconnect on the old connection (and maybe a close queue too) before reconnecting. The orphan connections will go away.
• to automatically clean these up, do
  • turn on the server's TCP Keep Alive,
  • and tell the MQ Queue Manager to use Keep Alive (QM.INI).

Top

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 "Examples of using MQCONN calls" of the "WebSphere MQ Clients" manual, available 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 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:

• Disable automatic reconnect
• Enable reconnect but only to the same queue manager
• Allow automatic reconnect
• Allow the client code to override this setting

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

url

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

Here is the stanza:

And these are the details:

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.

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.

WebSphere MQ automatic client reconnection with the WebSphere MQ classes for JMS : url code sample :

Exploiting the Automatic Client Reconnect feature in WebSphere MQ JMS 7.0.1 : Angel Rivera ppt

Top

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

url

Top

Si un cliente establece bien la IP+puerto a un canal SVRCONN, pero el nombre del canal no es el correcto, se produce una entrada en el log de errores al intentar conectar.

Top

• check the error logs
  • server error log <root>\qmgrs\<QM>\errors\AMQERR01.LOG
  • client error log <root>\errors\AMQERR01.LOG
• double check the MQSERVER variable
• does the amqsputc sample work ?
• is the network working ? Can you "tcp ping" the host ?
• is there an MQ listener running ?

TMM34 - MQ clients

Top

• que proceso se lanza cuando se conecta un nuevo canal cliente ? Parece ser amqrmppa.
• si se activa un thread, de que proceso cuelga ?

Top

• Morag Hughson
• Paul Clarke
• SALE(BACKUP) sample
• Using WebSphere MQ binding with a client channel definition table {mr vivica12}
  Includes Custom properties in the WebSphere Application Server/Process Server/ESB admin console
• MQ V6 Java and JMS clients and the client channel definition table (CCDT & JMS clients, ***)
• Using a Client Channel Definition Table (CCDT) in WebSphere MQ for Queue Manager Groups
• download MQ client : v6.0, v7.0, v7.1, v7.5.
• using WebSphere MQ automatic client reconnection with the WebSphere MQ classes for JMS
• storing CCDT in LDAP