| Author |
Message
|
| dotaneli |
 Posted: Tue Apr 22, 2014 8:14 am Post subject: (.Net) Using two different channel tables,switching MQCHLTAB |
 |
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
Hi everyone,
It's been a while since I last wrote to this respectful forum.
Good to be back.
An application we support, written in .Net, using MQ Client v 7.0.1.5, needs to access two different channel tables.
Table A - with 4 entries for the queue manager "A" (two sites, each site with two alternative channels).
Table B - with 4 entries for the queue manager "B", same (2 sites, 2 per site).
The application tries to connect through CDTT A and perform action "1"
and then changes the environment variables and performs action "2".
That's the way the environment variables are set:
Environment.SetEnvironmentVariable("MQCHLLIB", strChannelLib);
Environment.SetEnvironmentVariable("MQCHLTAB", strChannelFile);
After many tries we have isolated the behavior and determined that in this specific application, the first CDTT loaded is the one used by the client, and the attempt to alter the env variables during runtime changes nothing (doesn't switch CDTTs).
We know that because if we try to load CDTT B before A (as oppose to the regular scenario where CDTT A is loaded first), B is used and works properly, and remains the relevant CDTT even after the second set of environment variables.
Does anyone know of any limitation in changing the environment variables in runtime and switching CDTT? |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Apr 22, 2014 8:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Have you disconnected (MQDISC) from the queue manager before switching the CCDT variables?
_________________
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 |
|
|
| PaulClarke |
| Posted: Tue Apr 22, 2014 9:03 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I'm not sure about the C# environment but certainly the C environment is fraught with hazard if you try to change the environment on the fly. In particular you can have problems if the code doing the setting (for example putenv() the application EXE) is not the same chunk as the code doing the getting (for example getenv() in a DLL).
Anyway, I appreciate it is perhaps not ideal but another solution would be to use my MQSCX program which has the ability to merge one CCDT into another.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Apr 22, 2014 9:36 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Hi dotaneli,
When I look at how the MQ manuals instructs you to set and use those environment variables that you mentioned -> http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.con.doc/q016920_.htm
I would say that what you are doing is in the "unpredictable results" or "illegal use" arena.
Even if you are able to get it to work, that is not the way the manual instructs you to use those environment variables, and the current behavior of what you have achieved could change in a future release of MQ. I personally would not do that. |
|
| Back to top |
|
|
| dotaneli |
| Posted: Tue Apr 22, 2014 11:22 pm Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
Thank you all for your replies.
The need for two different channel tables is that of a good loosely coupled environment:
Should one application's qmgr move, change etc, the ability to only change that qmgr CDTT is of great value. Especially as a matter of policy, since a future scenario may include a connection to 10 different queue managers, where the need to replace an entire CDTT whenever one application moves is disproportionate.
Having said that, it seems to me that lacking a supported solution, we would indeed prefer to choose the supported - however tightly-coupled - solution, and not the one that just "works".
Using a single CDTT is our backup plan, if all other searches fail.
Re the suggestion to call MQDISC - well, since the program isn't a batch one but rather an ongoing service, both handles need to be left open.
If anyone has anymore thoughts on the matter I'm more than happy to hear. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Apr 22, 2014 11:27 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I would have thought there is no chance that changing the CCDT enviroment variables would have any effect on an open connection handle.
There is no reason why you can't MQDISC and then immediately MQCONN again - as long as you don't do it too frequently. Whether this would provide the CCDT switching you desire - is something you could test.
_________________
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 |
|
|
| dotaneli |
| Posted: Tue Apr 22, 2014 11:53 pm Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
Well, it's CCDT and not CDTT. I'm an idiot. Sorry 
MQDISC and MQCONN every few seconds is not a preferred design... is it? |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Apr 23, 2014 12:07 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
No, it's not a good design to be constantly connecting and disconnecting. Both are relatively expensive operations in terms of CPU and it will also introduce considerable latency.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Apr 23, 2014 1:31 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Hence my caveat
| Quote: |
| as long as you don't do it too frequently |
_________________
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 |
|
|
| fjb_saper |
| Posted: Wed Apr 23, 2014 7:27 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As you are using client connections, keep 2 connections open, one to each qmgr.
The same way you will have n sessions open, each session created from a specific connection and thus attached to a specific qmgr.
Now you would only need such a setup if you have to pick up messages from multiple qmgrs.
If it is just to dispatch messages to different qmgrs, the preferred method is to set up qmgr to qmgr connections and use only one qmgr with the application.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed Apr 23, 2014 10:55 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
|
| Back to top |
|
|
|
|
