| Author |
Message
|
| yasaboy |
 Posted: Thu Oct 23, 2014 11:14 pm Post subject: Channel Definition Table AMQCLCHL.TAB |
 |
|
Voyager
Joined: 23 Jun 2014
Posts: 90
|
Hi,
We have been using MQCONNX for connecting to Queue Managers upto now in our wrapper Lib.
Now we need to enable SSL and AMS inside our library. So we suppose of using the method AMQCLCHL.TAB to remote connect to Queue Manages while enabling SSL.
So as far as I understood when using client channel definition table we need to use MQCONN since the channel and connection parameters are read from AMQCLCHL.TAB file
So if there is no keystore defined and all can we still use the channel definition table to connect to the Queueus.
For example, I have done
| Code: |
DEFINE LISTENER('LISTENER.SSL') TRPTYPE(TCP) PORT(12345) CONTROL(QMGR)
DEFINE QLOCAL(TEST.INQUEUE1) REPLACE +
PUT(ENABLED) GET(ENABLED)
DEFINE CHANNEL(SSL.CLIENTS) chltype(SVRCONN) TRPTYPE(TCP)
DEFINE CHANNEL(SSL.CLIENTS) CHLTYPE(CLNTCONN) CONNAME('172.xx.xx.xx(12345)') QMNAME(SAM.TEST.SSL)
START LISTENER('LISTENER.SSL') |
copied the respected AMQCLCHL.TAB file to client mechine and set environmental varibles
| Code: |
export MQCHLLIB=/abc/xxx
export MQCHLTAB=AMQCLCHL.TAB |
but didnot set folllwing
Why cant I connect in this scenario using MQCONN ? it gives error 2393 ?
Why ?  |
|
| Back to top |
|
 |
| zpat |
| Posted: Fri Oct 24, 2014 12:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I would suggest you don't name queues or listeners with SSL since it can only confuse the matter.
Both the svrconn and clntconn definition must contain a suitable (and matching) cipherspec for SSL to work.
This is what enables SSL on a client channel.
You will need a key/truststore to validate the QM's certificate (you will need a cert of course). The MQSSLKEYR variable refers to that (not including the file suffix) and you will need to create a keystore of the CMS type for both the QM and the client application.
I am sure all this stuff is documented by IBM.
If you are going beyond SSL channels, to full message encyption - will this be as well as SSL channels or instead of?
_________________
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 |
|
|
| yasaboy |
| Posted: Fri Oct 24, 2014 12:34 am Post subject: |
|
|
Voyager
Joined: 23 Jun 2014
Posts: 90
|
| zpat wrote: |
I would suggest you don't name queues or listeners with SSL since it can only confuse the matter.
Both the svrconn and clntconn definition must contain a suitable (and matching) cipherspec for SSL to work.
This is what enables SSL on a client channel.
You will need a key/truststore to validate the QM's certificate (you will need a cert of course). The MQSSLKEYR variable refers to that (not including the file suffix) and you will need to create a keystore of the CMS type for both the QM and the client application.
I am sure all this stuff is documented by IBM.
If you are going beyond SSL channels, to full message encyption - will this be as well as SSL channels or instead of? |
Hi,
I am quite aware of that and have implemented and tested it already using amqsputc as described in http://usuaris.tinet.cat/sag/mq_ssl.htm.
But what I want to know is,
whether it is possible to use the channel definition table to connect to queues by using the AMQCLCHL.TAB file and MQCONN command when ssl is not enabled ? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Oct 24, 2014 1:09 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| yasaboy wrote: |
whether it is possible to use the channel definition table to connect to queues by using the AMQCLCHL.TAB file and MQCONN command when ssl is not enabled ? |
There is nothing stopping you from defining channels that don't have any SSL config (i.e. the default). Then all you need to do is select the correct channel to use
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 24, 2014 1:11 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Naturally it can be used without SSL.
But a given channel name has to be either non-SSL or SSL, with the corresponding entry in the CCDT.
We keep two CCDTs, one directs the app to SSL channels, and one directs them to non-SSL channels.
To make this simpler, we use the MO72 support pac to maintain the CCDTs, instead of the horrible standard method.
Please don't use SSL as part of any MQ object name (other then perhaps a SSL enabled channel), as it only serves to confuse.
_________________
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 |
|
|
| exerk |
| Posted: Fri Oct 24, 2014 1:12 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| yasaboy wrote: |
But what I want to know is,
whether it is possible to use the channel definition table to connect to queues by using the AMQCLCHL.TAB file and MQCONN command when ssl is not enabled ? |
Yes, because that's what a CCDT is intended for, but bearing in mind that SSL is 'enabled' within a channel pairing by populating the appropriate attribute with a valid cipher spec. What do your queue manager error logs state? What do your Client error logs state? If using your 'wrapper lib' to instantiate connection, does it try to instantiate an SSL connection?
Did you actually post all your definition attributes below, or did you make changes afterward, e.g. adding a cipher spec to the SVRCONN?
_________________
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 |
|
|
| yasaboy |
| Posted: Sun Oct 26, 2014 7:26 am Post subject: |
|
|
Voyager
Joined: 23 Jun 2014
Posts: 90
|
| exerk wrote: |
| yasaboy wrote: |
But what I want to know is,
whether it is possible to use the channel definition table to connect to queues by using the AMQCLCHL.TAB file and MQCONN command when ssl is not enabled ? |
Yes, because that's what a CCDT is intended for, but bearing in mind that SSL is 'enabled' within a channel pairing by populating the appropriate attribute with a valid cipher spec. What do your queue manager error logs state? What do your Client error logs state? If using your 'wrapper lib' to instantiate connection, does it try to instantiate an SSL connection?
Did you actually post all your definition attributes below, or did you make changes afterward, e.g. adding a cipher spec to the SVRCONN? |
Thanks for your reply. I could configure my Queue Manager in both SSL enabled and SSL disabled modes using the AMQCLCHL.TAB file. Now I can replace my MQCONNX to MQCONN in both SSL enabled and SSL disabled modes.
But now another problem rises.
Suppose I have ClientA. He uses channel1 to connect to INQ1 and channel2 to connect to INQ2. Both INQ1 and INQ2 are in same Queue manager TEST.QM1.
Suppose at a particular instance I want to connect to INQ2. So how can a .TAB file be used to select the correct channel which is channel2 at that particular instance ? Is it possible ? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Oct 26, 2014 7:48 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| yasaboy wrote: |
| So how can a .TAB file be used to select the correct channel which is channel2 at that particular instance ? Is it possible ? |
The .TAB file doesn't select; rather, it offers choices of qmgrs and channels for the application to MQCONNect to, based on if, and how, the qmgr is named in the application, such as:
MQCONN "qmgr-name"
MQCONN "*qmname"
MQCONN " "
Please take a few moments to read Introduction to MQ Clients presentation here:
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CDYQFjAD&url=https%3A%2F%2Fshare.confex.com%2Fshare%2F116%2Fwebprogram%2FHandout%2FSession8718%2FMQClients.pdf&ei=mxZNVMnhN6j2iQK7n4CACQ&usg=AFQjCNHBoMNqEBq15HFpxV71Wo788iYIiw&sig2=zqfjFyBbYhxl4GHDCDxW3A&bvm=bv.77880786,d.cGE&cad=rja
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Oct 26, 2014 10:36 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| yasaboy wrote: |
| Suppose I have ClientA. He uses channel1 to connect to INQ1 and channel2 to connect to INQ2. Both INQ1 and INQ2 are in same Queue manager TEST.QM1. |
If INQ1 and INQ2 are queue (a reasonable assumption I feel), what does it matter that ClientA uses a particular channel to get to them? You're just giving your application a choice of channels - for what purpose though? Or am I reading your post wrong?
_________________
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: Sun Oct 26, 2014 2:48 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Yasaboy,
It's not possible to ask MQ to select a different channel from the CCDT based on the queue you are going to open. This is not possible, for the most part, because of the order of the MQI calls. You connect to MQ (using say MQCONNX) and only after that has returned do you issue MQOPEN. So, the only way MQ would know which channel to use is if you gave it some hint on the MQCONNX verb. Well, the 'hint' you can give is the Queue Manager name on the MQXCONNX verb.
If you were adamant that you just want to 'hint' at what you are doing rather than select a channel name you could write a PreConnect exit. Then you could, for example, issue MQCONNX("INQ1") or MQCONNX("INQ2"). The PreConnect exit would know which channel to use for the 'service' it was being asked for. Of course the exit could also be more dynamic and change the result based on time of day, server availability and workload or any other factor you deem relavent.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
|
|
