| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Client Channel tables versus mqclient.ini |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Tue Jul 22, 2014 12:36 pm Post subject: MQ Client Channel tables versus mqclient.ini |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQ Client Channel tables versus mqclient.ini
I’m reevaluating my ancient position that apps should use MQ Client Channel tables as the preferred method of specifying their MQ connection details. While I appreciated that channel tables exposed 100% of the options available to MQ Clients (unlike MQSERVER), and allowed me to set all those gory details without them worrying about the gory details (unlike MQCONNX), I didn’t like the binary nature of the file. You couldn’t just pop it open in read only mode to see what you had. I know there are lots of ways to officially look at the contents, but app areas didn’t always have access to these tools so they contacted me. Again.
So, this mqclient.ini file is a nice plain text file. What I haven’t been able to find online is an evaluation of mqclient.ini versus MQ Client Channel Tables. If the mqclient.ini file had all the functionality of the channel table I would change by recommendation away from channel tables and over to mqclient.ini.
So, any thoughts on this? Does mqclient.ini offer everything Client Channel tables do, assuming the following:
The MQ Client app will not be specifying a QM name on its MQ connect.
The MQ Client app will have one channel table or mqclient.ini file per environment.
The MQ Client app will need to connect to 1 of 3 queue managers that act as backup to each other. But it doesn’t care which one it connects to, and it only needs to be connected to one at a time.
The one benefit that client channel tables have over mqclient.ini that I can see is if the app needs to control which one of the QMs it wants to connect to, it can with channel tables (supply the QM name), but its not possible in mqclient.ini. Or is it…..If the app uses mqclient.ini (with 3 hostnames) and supplies a QM name – would the MQCONNX call fail with a 2058 and it would keep retrying until it ‘hit’ the right QM?
Any other big differences between the 2 methods?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Jul 22, 2014 12:55 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The CHANNELS and SSL stanzas in the mqclient.ini file (as far as I am aware) only take the place of the environment variables (plus adding other bells and whistles), e.g.
ChannelDefinitionDirectory = MQCHLLIB
ChannelDefinitionFile = MQCHLTAB
SSLKeyRepository = MQSSLKEYR
The only stanzas within it that I know of that will give you granular control is the ServerConnectionParms stanza, and that acts just like MQSERVER, so no SSL etc.
I use mqclient.ini in preference to the environment variables now because it now means I have more control - I don't have to rely on the client settings its environment where there are multiple clients on the server.
Will all three of the queue managers be defined within your CCDT?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Tue Jul 22, 2014 1:26 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Hi Peter,
Well, there are some advantages that come to mind
- Validation time
The CCDT is validated at define time so you know that the channel definitions are complete and complete. Admittedly you don’t know that the IP address is correct but you do know that CONNAME is spelled correctly. Runtime validation, like the mqclient.ini file is more hazardous, spell the stanza wrong and the whole thing is completely ignored.
- Independence
An INI file may contain lots of data pertinent to the particular machine it’s running on. Having a separate file with the channel definitions allows you to share only what needs to be shared.
- Location
With the CCDT it is easy to put the file on a file server and have all your clients reference the same file. If you have 100’s or 1000’s of client then this can be of real benefit rather than having to update hundreds of locations. It offers a simple yet effective single (or at least vastly reduced) point of administration.
- Familiarity
A channel definitions is actually quite complicated. It contains many fields, some of which are repeated. A full channel definition rendered in an INI file (or XML) would be quite complicated and yet another syntax to learn. People will still need to be able to issue DEFINE CHANNEL for their SVRCONN channels, does it not make sense to have the very similar CLNTCONN channel defined the same way?
I agree that having a human readable file rather than a binary file can be more convenient in many circumstances. That was one of the main reasons I added CCDT editing to MO72. This, as you probably know, has now been incorporated into MQ V8. Before long I also hope to have CCDT editing in MQSCX. With such tools it is not that onerous to display or change the definitions as required. After all, why are client channel definitions that much different from any other MQ object? Would you prefer to change a queue definition or a sender channel by editing an XML file?
One thing you could consider is PreconnectExit. This exit is pretty flexible. It wouldn’t be hard to write an exit to parse whatever format of channel definition you liked and you could therefore, essentially, implement this feature yourself. If you felt brave you could even submit it as a SupportPac. Or indeed a company like MQGem could do it if someone felt strongly enough about it to dip in their pockets.
I guess the bottom line is that it all depends on your circumstances which is why there are so many ways of defining a CLNTCONN channel today. There are already at least 5 different ways you can pass the channel definition to a client program. However, I don’t doubt that for some situations further mechanisms would be a better fit.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 23, 2014 3:37 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Thanks exerk, I was counting on you replying as I remember you frequently mentioning mqclient.ini in your postings. I just never really paid much attention to the mqclient.ini.
| exerk wrote: |
The CHANNELS and SSL stanzas in the mqclient.ini file (as far as I am aware) only take the place of the environment variables (plus adding other bells and whistles), e.g.
ChannelDefinitionDirectory = MQCHLLIB
ChannelDefinitionFile = MQCHLTAB
SSLKeyRepository = MQSSLKEYR
|
I like it, this one file can replace the need to have a whole bunch of environment variables set on the client machine. And the InfoCenter, er, Knowledge Center explains very clearly where this file can be and how the client finds its.
| exerk wrote: |
The only stanzas within it that I know of that will give you granular control is the ServerConnectionParms stanza, and that acts just like MQSERVER, so no SSL etc.
|
I had assumed incorrectly that since there was an SSL stanza and an Exits stanza I could define the basic properties of the connection with the ServerConnectionParms stanza, then layer on the SSL or Exit details with those stanzas. But upon further inspection (OK, I admit it - upon actually doing my first real inspection  ) of those 2 stanzas I see that they don't provide a way to specify the basic details of SSL or Exits that you can on a CLNTCONN channel.
| exerk wrote: |
Will all three of the queue managers be defined within your CDT? |
Yes, the plan would be for the clients to be able to:
A. hit any one of the 3
B. Or, get load balanced across all 3
C. Or, hit one of the 3 primarily, then another as a secondary, then the last as a tertiary
D. And, hit a specific one of the 3
There will be exits and/or SSL involved.
I now understand that mqclient.ini can't do this on its own. A Client Channel Table is still needed for use cases like this, although the mqclient.ini file can compliment it.
One Client Channel Table will not suffice for all 4 use cases above - A,B,C and D. For the clients that need A+D, that's one table. For the clients that need C+D for example, that's another table. But it would be another table anyway since they would have their own unique client channel names.
For me the bottom line is that for very simple cases mqclient.ini can replace a client channel table, but so could MQSERVER or MQCONNX. But in general Client Channel Tables are still the preferred way to go (for me) and the mqclient.ini file can compliment the deployment.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jul 23, 2014 3:49 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The MO72 feature of MQ v8 - does it allow the building of a CCDT at a given MQ version (as the MO72 support pac does)?
For example I might want to build a CCDT compatible with MQ v701 (and above) as it will be a long time (probably years) before all of our MQ clients are at MQ v8.
Of course I can continue to use the MO72 support pac (and will be doing just that).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 23, 2014 3:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Paul, thanks for all that great info. Back in the day (pre MQ 6.0) where not all MQ Clients could use a Channel Table we got into the mind set of the Client Channel Tables being a nice option, but frequently not available as an option.
Now that they are available for all MQ Clients its the way to go for me. And as I stated in my response to exerk, the mqclient.ini can compliment a MQ Client Channel Table, but rarely will it be able to replace it.
This post:
https://www.ibm.com/developerworks/community/blogs/messaging/entry/bitesize_blogging_mq_v8_client_mqsc?lang=en
talks about runmqsc being available for MQ Clients in MQ 8 and being able to manage your own (local to the MQ Client) Client Channel Table. So that's cool, finally a way to create these tables without needing a full Queue Manager. But I'm guessing this produces channel tables that only MQ 8 and newer MQ Client will be able to use. I don't see a way to produce an MQ 7.1 or 7.5 table this way. Sigh, so without you there to get MO72 beefed up to be able to downgrade a MQ 8 channel table to MQ 7.*, it looks like I still have to maintain a 7.* queue manger to create channel tables for 7.* clients.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jul 23, 2014 4:07 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| exerk wrote: |
Will all three of the queue managers be defined within your CDT? |
Yes, the plan would be for the clients to be able to:
A. hit any one of the 3
B. Or, get load balanced across all 3
C. Or, hit one of the 3 primarily, then another as a secondary, then the last as a tertiary
D. And, hit a specific one of the 3
There will be exits and/or SSL involved.
I now understand that mqclient.ini can't do this on its own. A Client Channel Table is still needed for use cases like this, although the mqclient.ini file can compliment it.
One Client Channel Table will not suffice for all 4 use cases above - A,B,C and D. For the clients that need A+D, that's one table. For the clients that need C+D for example, that's another table. But it would be another table anyway since they would have their own unique client channel names. |
If you have multiple mqclient.ini files, and don't want to scatter them all over different directories on a server, or want to maintain centralized storage and management of the files, you could always have the application set the MQCLNTCF variable for the path and file applicable to it.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
