MQ Client Channel Tables versus mqclient.ini

[Potkay, Peter M (CTO Architecture + Engineering)]

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

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Paul Clarke]

Hi Peter,

Well, there are some advantages that come to mind
a.. 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.

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

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

d.. 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
www.mqgem.com

From: Potkay, Peter M (CTO Architecture + Engineering)
Sent: Tuesday, July 22, 2014 9:35 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: MQ Client Channel Tables versus mqclient.ini

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



************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi Peter,

mqclient.ini doesn’t offer anything like the capability of a channel table.

For connection parameters, it supports only a single set, and only the equivalent of the MQSERVER environment variable. This means no SSL for a start. Also, no groups to enable load balancing between queue managers, and only simple failover strategies with multiple IP addresses.

On the other hand, there are things in the mqclient.ini (like the location to use for loading exits) that can’t be specified in the channel table.

So they aren’t really designed for the same purpose, or to be replacements for the other.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by Potkay, Peter M (CTO Architecture + Engineering)
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.
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
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Thanks Paul and Neil. I now understand that for very basic use cases mqclient.ini can be used instead of MQ Client Channel tables. But for basic use cases so could MQSERVER or MQCONNX. Otherwise mqclient.ini is not a replacement for channel tables.

I made a bad assumption when I quickly skimmed through the doc on the mqclient.ini - I saw a SSL and Exits stanza and assumed that is where I could all the SSL and Exit details like I can in a channel table. Uh, no.

So for me the preferred way is still MQ Client Channel Tables, and an mqclient.ini file can be used to compliment the channel table.

If only there was a way to produce MQ Client Chanel tables without needing old QMs to produce old channel tables. I see in MQ 8 that the MQ Client can now manage its own channel table.
https://www.ibm.com/developerworks/community/blogs/messaging/entry/bitesize_blogging_mq_v8_client_mqsc?lang=en

But looks like that means only MQ 8 compatible channel tables.
I have used MO72 in the past to downgrade channel tables (take a 7.0 and make it 6.0 compatible), but I'm guessing that MO72 won't be updated to allow MQ 8 tables to be downgraded. So that means I have to keep an MQ 7.* Queue Manager around to manage/produce MQ 7.* compatible channel tables.


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Tuesday, July 22, 2014 7:09 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ Client Channel Tables versus mqclient.ini

Hi Peter,

mqclient.ini doesn't offer anything like the capability of a channel table.

For connection parameters, it supports only a single set, and only the equivalent of the MQSERVER environment variable. This means no SSL for a start. Also, no groups to enable load balancing between queue managers, and only simple failover strategies with multiple IP addresses.

On the other hand, there are things in the mqclient.ini (like the location to use for loading exits) that can't be specified in the channel table.

So they aren't really designed for the same purpose, or to be replacements for the other.

Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-o/d1HoMt0QriyhYAg/***@public.gmane.org] [phone]<tel:+61%20414%20615%20334>[cid:image002.jpg-o/d1HoMt0QriyhYAg/***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-o/d1HoMt0QriyhYAg/***@public.gmane.org]

On 23 Jul 2014, at 6:35 am, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>> wrote:


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


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Paul Clarke]

I think it probably is quite likely that we’ve seen the last of MO72. However, shortly I expect full CCDT editing to be added to MQSCX (it was there in the Beta) which means that MQSCX can do pretty much whatever MO72 could do and an awful lot of other nifty things besides. Even with CCDTs it can do more since it allows you to merge two CCDT files together. Admittedly the program isn’t free, like MO72 was, but the licence fee is very low and a bargain at twice the price

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, July 23, 2014 1:04 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ Client Channel Tables versus mqclient.ini

Thanks Paul and Neil. I now understand that for very basic use cases mqclient.ini can be used instead of MQ Client Channel tables. But for basic use cases so could MQSERVER or MQCONNX. Otherwise mqclient.ini is not a replacement for channel tables.



I made a bad assumption when I quickly skimmed through the doc on the mqclient.ini – I saw a SSL and Exits stanza and assumed that is where I could all the SSL and Exit details like I can in a channel table. Uh, no.



So for me the preferred way is still MQ Client Channel Tables, and an mqclient.ini file can be used to compliment the channel table.



If only there was a way to produce MQ Client Chanel tables without needing old QMs to produce old channel tables. I see in MQ 8 that the MQ Client can now manage its own channel table.

https://www.ibm.com/developerworks/community/blogs/messaging/entry/bitesize_blogging_mq_v8_client_mqsc?lang=en



But looks like that means only MQ 8 compatible channel tables.

I have used MO72 in the past to downgrade channel tables (take a 7.0 and make it 6.0 compatible), but I’m guessing that MO72 won’t be updated to allow MQ 8 tables to be downgraded. So that means I have to keep an MQ 7.* Queue Manager around to manage/produce MQ 7.* compatible channel tables.





Peter Potkay



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Tuesday, July 22, 2014 7:09 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ Client Channel Tables versus mqclient.ini



Hi Peter,



mqclient.ini doesn’t offer anything like the capability of a channel table.



For connection parameters, it supports only a single set, and only the equivalent of the MQSERVER environment variable. This means no SSL for a start. Also, no groups to enable load balancing between queue managers, and only simple failover strategies with multiple IP addresses.



On the other hand, there are things in the mqclient.ini (like the location to use for loading exits) that can’t be specified in the channel table.



So they aren’t really designed for the same purpose, or to be replacements for the other.



Regards,



Neil
--
Neil Casey

Senior Consultant | Syntegrity Solutions


[phone] neil.casey-VLLIzlmz+***@public.gmane.org

Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006

Analyse >> Integrate >> Secure >> Educate






On 23 Jul 2014, at 6:35 am, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org> wrote:





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



************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************




--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com






--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Potkay, Peter M (CTO Architecture + Engineering)]

Will it be able to produce MQ Client Channel Tables? Or only edit/alter existing ones produced outside the tool?


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul Clarke
Sent: Wednesday, July 23, 2014 8:54 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: MQ Client Channel Tables versus mqclient.ini

I think it probably is quite likely that we’ve seen the last of MO72. However, shortly I expect full CCDT editing to be added to MQSCX (it was there in the Beta) which means that MQSCX can do pretty much whatever MO72 could do and an awful lot of other nifty things besides. Even with CCDTs it can do more since it allows you to merge two CCDT files together. Admittedly the program isn’t free, like MO72 was, but the licence fee is very low and a bargain at twice the price [Smile]

Cheers,
Paul.

Paul Clarke
www.mqgem.com<http://www.mqgem.com>

From: Potkay, Peter M (CTO Architecture + Engineering)<mailto:***@THEHARTFORD.COM>
Sent: Wednesday, July 23, 2014 1:04 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: MQ Client Channel Tables versus mqclient.ini

Thanks Paul and Neil. I now understand that for very basic use cases mqclient.ini can be used instead of MQ Client Channel tables. But for basic use cases so could MQSERVER or MQCONNX. Otherwise mqclient.ini is not a replacement for channel tables.

I made a bad assumption when I quickly skimmed through the doc on the mqclient.ini – I saw a SSL and Exits stanza and assumed that is where I could all the SSL and Exit details like I can in a channel table. Uh, no.

So for me the preferred way is still MQ Client Channel Tables, and an mqclient.ini file can be used to compliment the channel table.

If only there was a way to produce MQ Client Chanel tables without needing old QMs to produce old channel tables. I see in MQ 8 that the MQ Client can now manage its own channel table.
https://www.ibm.com/developerworks/community/blogs/messaging/entry/bitesize_blogging_mq_v8_client_mqsc?lang=en

But looks like that means only MQ 8 compatible channel tables.
I have used MO72 in the past to downgrade channel tables (take a 7.0 and make it 6.0 compatible), but I’m guessing that MO72 won’t be updated to allow MQ 8 tables to be downgraded. So that means I have to keep an MQ 7.* Queue Manager around to manage/produce MQ 7.* compatible channel tables.


Peter Potkay

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Tuesday, July 22, 2014 7:09 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: MQ Client Channel Tables versus mqclient.ini

Hi Peter,

mqclient.ini doesn’t offer anything like the capability of a channel table.

For connection parameters, it supports only a single set, and only the equivalent of the MQSERVER environment variable. This means no SSL for a start. Also, no groups to enable load balancing between queue managers, and only simple failover strategies with multiple IP addresses.

On the other hand, there are things in the mqclient.ini (like the location to use for loading exits) that can’t be specified in the channel table.

So they aren’t really designed for the same purpose, or to be replacements for the other.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:***@01CFA655.B4E4D3C0] [phone]<tel:+61%20414%20615%20334>[cid:***@01CFA655.B4E4D3C0] ***@syntegrity.com.au <mailto:***@syntegrity.com.au>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:***@01CFA655.B4E4D3C0]

On 23 Jul 2014, at 6:35 am, Potkay, Peter M (CTO Architecture + Engineering) <***@THEHARTFORD.COM<mailto:***@THEHARTFORD.COM>> wrote:

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


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Paul Clarke]

Yes it can produce CCDTs from scratch and of whatever MQ version you like.

Cheers,
Paul.

Paul Clarke
www.mqgem.com

From: Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, July 23, 2014 2:09 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ Client Channel Tables versus mqclient.ini

Will it be able to produce MQ Client Channel Tables? Or only edit/alter existing ones produced outside the tool?





Peter Potkay



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Paul Clarke
Sent: Wednesday, July 23, 2014 8:54 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ Client Channel Tables versus mqclient.ini



I think it probably is quite likely that we’ve seen the last of MO72. However, shortly I expect full CCDT editing to be added to MQSCX (it was there in the Beta) which means that MQSCX can do pretty much whatever MO72 could do and an awful lot of other nifty things besides. Even with CCDTs it can do more since it allows you to merge two CCDT files together. Admittedly the program isn’t free, like MO72 was, but the licence fee is very low and a bargain at twice the price



Cheers,
Paul.



Paul Clarke
www.mqgem.com



From: Potkay, Peter M (CTO Architecture + Engineering)

Sent: Wednesday, July 23, 2014 1:04 PM

To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org

Subject: Re: MQ Client Channel Tables versus mqclient.ini



Thanks Paul and Neil. I now understand that for very basic use cases mqclient.ini can be used instead of MQ Client Channel tables. But for basic use cases so could MQSERVER or MQCONNX. Otherwise mqclient.ini is not a replacement for channel tables.



I made a bad assumption when I quickly skimmed through the doc on the mqclient.ini – I saw a SSL and Exits stanza and assumed that is where I could all the SSL and Exit details like I can in a channel table. Uh, no.



So for me the preferred way is still MQ Client Channel Tables, and an mqclient.ini file can be used to compliment the channel table.



If only there was a way to produce MQ Client Chanel tables without needing old QMs to produce old channel tables. I see in MQ 8 that the MQ Client can now manage its own channel table.

https://www.ibm.com/developerworks/community/blogs/messaging/entry/bitesize_blogging_mq_v8_client_mqsc?lang=en



But looks like that means only MQ 8 compatible channel tables.

I have used MO72 in the past to downgrade channel tables (take a 7.0 and make it 6.0 compatible), but I’m guessing that MO72 won’t be updated to allow MQ 8 tables to be downgraded. So that means I have to keep an MQ 7.* Queue Manager around to manage/produce MQ 7.* compatible channel tables.





Peter Potkay



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Tuesday, July 22, 2014 7:09 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ Client Channel Tables versus mqclient.ini



Hi Peter,



mqclient.ini doesn’t offer anything like the capability of a channel table.



For connection parameters, it supports only a single set, and only the equivalent of the MQSERVER environment variable. This means no SSL for a start. Also, no groups to enable load balancing between queue managers, and only simple failover strategies with multiple IP addresses.



On the other hand, there are things in the mqclient.ini (like the location to use for loading exits) that can’t be specified in the channel table.



So they aren’t really designed for the same purpose, or to be replacements for the other.



Regards,



Neil
--
Neil Casey

Senior Consultant | Syntegrity Solutions


[phone] neil.casey-VLLIzlmz+***@public.gmane.org

Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006

Analyse >> Integrate >> Secure >> Educate






On 23 Jul 2014, at 6:35 am, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org> wrote:



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



************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************




--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com






--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************




--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com




--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************



--------------------------------------------------------------------------------

List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Tim Zielke]

So the v8 runmqsc enhancements for administering a CCDT don't support being able to specify what version of the CCDT you want to create or alter (i.e. v6, v7, v8)? That seems like a big take away from what MO72 supported (working on different versions of the CCDT), if it does not. I took a quick look at the v8 manual, and I don't see where you can specify a version for the CCDT.

Thanks,
Tim

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, July 23, 2014 7:05 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ Client Channel Tables versus mqclient.ini

Thanks Paul and Neil. I now understand that for very basic use cases mqclient.ini can be used instead of MQ Client Channel tables. But for basic use cases so could MQSERVER or MQCONNX. Otherwise mqclient.ini is not a replacement for channel tables.

I made a bad assumption when I quickly skimmed through the doc on the mqclient.ini - I saw a SSL and Exits stanza and assumed that is where I could all the SSL and Exit details like I can in a channel table. Uh, no.

So for me the preferred way is still MQ Client Channel Tables, and an mqclient.ini file can be used to compliment the channel table.

If only there was a way to produce MQ Client Chanel tables without needing old QMs to produce old channel tables. I see in MQ 8 that the MQ Client can now manage its own channel table.
https://www.ibm.com/developerworks/community/blogs/messaging/entry/bitesize_blogging_mq_v8_client_mqsc?lang=en

But looks like that means only MQ 8 compatible channel tables.
I have used MO72 in the past to downgrade channel tables (take a 7.0 and make it 6.0 compatible), but I'm guessing that MO72 won't be updated to allow MQ 8 tables to be downgraded. So that means I have to keep an MQ 7.* Queue Manager around to manage/produce MQ 7.* compatible channel tables.


Peter Potkay

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Tuesday, July 22, 2014 7:09 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: MQ Client Channel Tables versus mqclient.ini

Hi Peter,

mqclient.ini doesn't offer anything like the capability of a channel table.

For connection parameters, it supports only a single set, and only the equivalent of the MQSERVER environment variable. This means no SSL for a start. Also, no groups to enable load balancing between queue managers, and only simple failover strategies with multiple IP addresses.

On the other hand, there are things in the mqclient.ini (like the location to use for loading exits) that can't be specified in the channel table.

So they aren't really designed for the same purpose, or to be replacements for the other.

Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-***@public.gmane.org] [phone]<tel:+61%20414%20615%20334>[cid:image002.jpg-***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-***@public.gmane.org]

On 23 Jul 2014, at 6:35 am, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>> wrote:

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


************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html