MQ Client channel definition tables (also known as CCDT's) have been part of MQ for as long as I can remember, they provide a way of configuring advanced client connections to queue managers. The simplest client connections can of course be configured with just a channel name and connection name for example with the MQSERVER environment variable, for example;
This then provides MQ with enough information for an application to connect over TCP/IP to a single remote queue manager at 'myhost' on port 1414, via channel SYSTEM.DEF.SVRCONN. If you need to go beyond a simple connection such as this, then you'll need a different solution. If any of the following apply;
- Need to add security through SSL/TLS cipherspecs or channel security exits
- Need to enable or tweak other non-default settings such as channel compression
- Need to provide workload balancing of connections without network sprayer
- Need to define more than one queue manager connection
...then a client channel definition table is one way to meet these requirements.
The client channel definition table is implemented as a file, by default this is called AMQCLCHL.TAB and it is held in a binary format. The file would normally be copied from where it was defined to where the client applications are running. Traditionally the client channel definition table has always been generated by the queue manager and updated every time a channel type of CLTCN is created, altered or deleted. From MQ V8 the ability to create, alter, delete and view the contents of the file was added to clients through runmqsc running in a non-connected mode (runmqsc -n). Although the client-side runmqsc capabilities address some of the issues involved with maintaining client connection definitions, it doesn't solve one of the major issues, that is, how to push out channel definition changes to all of the clients that will use it ?
Until now, MQ administrators would need to coordinate pushing out new copies of the CCDT to each client, or, host the file on a networked filesystem and mount this on every client. JMS and fully managed .NET client applications have also been able to locate a CCDT file by specifying a local file or a ftp or http resource using the CCDTUrl property on a connection factory. For all native client applications (C/C++, COBOL, RPG) the file had to be accessible via a local or mounted network filesystem, however this is no longer true.
MQV9 adds the same capability to native (C/C++, COBOL & RPG) and unmanged .NET applications to 'pull' the CCDT from a URL, whether that be a local file, ftp or http resource. The default caching behavior of MQ clients is that a CCDT file will only be pulled down if the file modification time is different to the last time it was retrieved. As with most client configuration options, there are a variety of ways in which the URL location can be provided;
- CCDTUrlPtr/CCDTUrlOffset via MQCNO structure being passed into MQCONNX MQI call
- MQCCDTURL environment variable
- ChannelDefinitionDirectory attribute in Channels stanza of mqclient.ini
Both authenticated and unauthenticated URLs are supported, here are some examples;
If you wanted to use this support with ftp or http, then that still means you would need to host the CCDT file on a server, but with the new V9 support this means that all of your client applications could automatically pick up changes to channel definitions without manually pushing out updates or needing to mount a networked filesystem on each client.