views:

214

answers:

3

I need to change the C++ code to connect with WebSphere MQ using Client Channel defnition table. There are about 5000+ MQ clients and 10 MQ Servers on Windows 2003 with v6.0. Please help me if any one using C++ with CCDT.

+2  A: 

Set the MQCHLLIB and MQCHLTAB environment variables to point to the channel table as described in "Using WebSphere MQ environment variables." Next, set SSLKEYR as described in the same section of the manual. These will allow the app to find the CCDT and the KDB files. Be sure that the CCDT contains channel definitions which specify the right SSLCIPH and then connect as usual. No code changes should be required.

A word of advice, use the WMQ v7 client, even though the server is at v6. The client is backward compatible as long as you do not try to use the v7 features like automatic reconnect. However, v6 is end-of-life next year and if you want to avoid retesting and redeployment - or running an unsupported version - deploy as much as possible on v7 components.

T.Rob
Hi Rob,Thanks for your quick response. I'm MQ Admin and none from application team has experience with C++ Code as they using the same which was developed 8 yrs back. And the code is taking the MQ connection parameters from .xml file. If nothing has to be changed in code then by default client connects to queue managers using .xml file. Please correct me if i'm wrong on this.
Nikhil
Depends on what's in the XML file and how the app connects. If the app uses MQCONNX and is not currently filling in the SSL parameters then it really does need to be changed. On the other hand, if the app is using the CCDT then adding the SSLKEYR environment variable allows it to find the KDB file and building a new CCDT with the SSL channel parms included would complete the conversion. So it really depends on how the app is coded to know which of these is the correct action to take.
T.Rob
A: 

XML file has MQ Servers connection information like host name, queue manager name, channel and port. Client first try to connect to 1st queue manager in xml file and if it fails to establish the connection then it goes for 2nd queue manager. Client connections are not load balanced and all the servers are in Cluster. I'm sure clients connecting using MQCONN and will aslo confirm the same with developers. I read about new features in v7.0 about auto reconnection and clients selecting the queue managers randomly from Client Channel definition table.

Nikhil
Big difference here between MQCONN and MQCONNX. If the XML file contains host, channel and port then the applications are using MQCONNX which allows you to specify all the connection details. In this case, it will be necessary to add the SSL CipherSpec to the connection options as described here: http://bit.ly/aMLFnO Of course, you still need to tell the application where to find the KDB file and that's the SSLKEYR environment variable as described earlier.
T.Rob
To find out whether application using MQCONN or MQCONNX, does the below command to trace the MQ API Calls helps?strmqtrc -x all -t api (On Windows)strmqtrc -t api
Nikhil
Hi Rob,I enabled the trace in test server using "strmqtrc -t api" and found MQCONN in the output files. Does this confirms we not using MQCONNX?Development team is in offshore and they are unable to answer my question on MQCONN and MQCONNX. So i'm checking whether i can find by myself.
Nikhil
I don't know for sure whether MQCONNX show up in trace as such. However the *only* parameter for MQCONN is the QMgr name, a 48-character string. If you see host, port and channel in the trace of the MQCONN then it's actually a MQCONNX call. There's a whole different discussion here about how you QA code from offshore teams if you do not have access to the source but we can save that for another day.
T.Rob
I looked into the source code and no where i saw mentioning MQCONN or MQCONNX. I can see only WebSphere MQ C++ classes. Please help me how can i find it out. Is it possible by enabling the trace on Client?
Nikhil
A: 

Please let me know how can i send you the trace file which has MQCONN.

Nikhil
Please don't. The original question stated that you have a need "to change the C++ code". This presumes access to the code. Reverse engineering from a trace is not worth the effort if the code is available. If the code is actually not available then the offshore team must be accountable for updating it and have the skills to do so. This one is sounding more and more like a contractual problem and skills gaps on the dev team. If you can solve those, all these technical issues go away. If you must do this by reverse engineering, please open a PMR and let the IBM Support team help you out.
T.Rob