| Author |
Message
|
| J.D |
 Posted: Mon Jul 05, 2010 1:52 pm Post subject: MQCOONX with CCDT |
 |
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Mon Jul 05, 2010 3:21 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
CCDT can be used with MQCONNX call, but if you code the MQCNO to point to a MQCD that specifies a CLNTCONN channel, it will override any CCDT.
_________________
Glenn |
|
| Back to top |
|
|
| J.D |
| Posted: Mon Jul 05, 2010 3:42 pm Post subject: |
|
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
| gbaddeley wrote: |
| CCDT can be used with MQCONNX call, but if you code the MQCNO to point to a MQCD that specifies a CLNTCONN channel, it will override any CCDT. |
Hi Glenn,
I'm MQ admin not a developer. So i do not know much about MQCNO and MQCD. 
Requirement is to enable client-server communication with SSL. Multiple Applications from single client host connect with Qmgr using single SVRCONN channel and there are 5000+ such client machines with similar apps. There are no CLNTCONN channel definitins on MQ Servers. Does this confirm that code is not pointing to MQCD?
Applications use IBM WebSphere MQ C++ classes.
Clients and Servers are on Win 2003 with v6.0.2x
Thank You!!
_________________
IBM WebSphere MQ & WAS Administrator |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 05, 2010 3:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| J.D wrote: |
| There are no CLNTCONN channel definitins on MQ Servers. Does this confirm that code is not pointing to MQCD? |
No. It means that no CCDT table(s) are in use, indicating that the applications are either using MQCONNX or MQCONN with an MQServer variable.
All these methods are documented in the Clients manual if you need more details.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| J.D |
| Posted: Mon Jul 05, 2010 3:59 pm Post subject: |
|
|
Voyager
Joined: 18 Dec 2009
Posts: 92
Location: United States
|
| Vitor wrote: |
| J.D wrote: |
| There are no CLNTCONN channel definitins on MQ Servers. Does this confirm that code is not pointing to MQCD? |
No. It means that no CCDT table(s) are in use, indicating that the applications are either using MQCONNX or MQCONN with an MQServer variable.
All these methods are documented in the Clients manual if you need more details. |
Yes, the Client is not using the CCDT now. It takes the connection details from .xml file and Sample .xml looks like below:
<qm-property name="qm0"
queueManager="MQEPSCA"
channel="DF.POS.SVRCONN"
errorThreshold="3"
host="MQEPSCA"
transportType="tcp"
port="1430" />
_________________
IBM WebSphere MQ & WAS Administrator |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jul 06, 2010 4:01 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
<qm-property name="qm0"
queueManager="MQEPSCA"
channel="DF.POS.SVRCONN"
errorThreshold="3"
host="MQEPSCA"
transportType="tcp"
port="1430" /> |
If its a C++ app using the MQ classes, it looks like the app is populating an ImqChannel class from the XML. I suspect that app code changes may be required to set the SSL attributes in ImqChannel.
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 07, 2010 1:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| J.D wrote: |
| There are no CLNTCONN channel definitins on MQ Servers. Does this confirm that code is not pointing to MQCD? |
No. It means that no CCDT table(s) are in use, indicating that the applications are either using MQCONNX or MQCONN with an MQServer variable. |
Strictly speaking, all that it means is that those MQ servers do not host queue managers that still have CLNTCONN definitions that could have been used to create a CCDT.
It does not mean anything about the application itself, or that the app developers didn't create their own CCDT on their own local qmgr, or that someone else didn't use one of the production qmgrs to create a CCDT at a previous point in time and then "cleaned up the evidence" afterwards. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 07, 2010 3:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
Strictly speaking, all that it means is that those MQ servers do not host queue managers that still have CLNTCONN definitions that could have been used to create a CCDT.
It does not mean anything about the application itself, or that the app developers didn't create their own CCDT on their own local qmgr, or that someone else didn't use one of the production qmgrs to create a CCDT at a previous point in time and then "cleaned up the evidence" afterwards. |
Good point!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 07, 2010 8:13 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| mqjeff wrote: |
Strictly speaking, all that it means is that those MQ servers do not host queue managers that still have CLNTCONN definitions that could have been used to create a CCDT.
It does not mean anything about the application itself, or that the app developers didn't create their own CCDT on their own local qmgr, or that someone else didn't use one of the production qmgrs to create a CCDT at a previous point in time and then "cleaned up the evidence" afterwards. |
Good point! |
And if you use MO72 you don't even need a qmgr to create a chl table... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
