| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to determine what mq connectivity is being used? |
« View previous topic :: View next topic » |
| Author |
Message
|
| lekalif |
 Posted: Fri Apr 25, 2008 4:34 am Post subject: How to determine what mq connectivity is being used? |
 |
|
Newbie
Joined: 21 Sep 2006
Posts: 5
|
Hi all, has anyone ever encountered this challenge?
Source code uses mqm.dll to connect, perform browse,puts/gets etc.
We want to change this source to use Mqic32.dll (mq client)
Can anyone think of a way (from within the code or other?) to determine which connection is being used? Local (mqm.dll) or remote (mq client)
thks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Apr 25, 2008 4:43 am Post subject: Re: How to determine what mq connectivity is being used? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lekalif wrote: |
Can anyone think of a way (from within the code or other?) to determine which connection is being used? Local (mqm.dll) or remote (mq client)
|
One of the advantages WMQ offers is that the application can't see how (or where) it's connected, and by extension where the messages it sends are going or where the messages it receives are coming from.
What's the requirement here? Why does the application need to know how it's connected? In theory at least, you change a binding connection to a client connection by relinking, though at an administrative level you need to be aware of the differences obviously (e.g. a client connection needs a network link that a bindings does not).
Again from an administrative level, you can determine client connectivity by the client channels the queue manager is running. Or not.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lekalif |
| Posted: Fri Apr 25, 2008 5:08 am Post subject: |
|
|
Newbie
Joined: 21 Sep 2006
Posts: 5
|
Our requirement is somewhat loose at this point...it's more of a preference/wish to prevent us from compiling and deploying code that only works with mqm.dll (for example). At this point, it's a small change to the source (actually 1 statement;
File Include:mqm.dll OR
File Include:mqic32.dll) to use one type of connection over the other.
What we'd like is to have code that checks the library type being used and logs the connection method. This would speed up our testing cylce slightly. Also, we maintain 1 source repository for all customers. With some customers starting to run clustered/shared mq environments, our product now must also run as mq client connection.
thanks very much for your speedy reply! |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 25, 2008 5:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lekalif wrote: |
At this point, it's a small change to the source (actually 1 statement;
File Include:mqm.dll OR
File Include:mqic32.dll) to use one type of connection over the other. |
What language is this? Normally the source is identical for both client & server versions (because things like the #include are the same) and differing versions are produced by linking the object with one or other of the dlls.
| lekalif wrote: |
| What we'd like is to have code that checks the library type being used and logs the connection method. |
Be aware that the majority of sites have both client & sever libs installed, and can use both. An example would be WMQ applications using client connections for portability except for a few which use XA transaction control and are therefore server side.
| lekalif wrote: |
With some customers starting to run clustered/shared mq environments, our product now must also run as mq client connection.
|
Clustering has nothing to do with client or server connection methods, especially under v6.
The obvious (though possibly impractical) solution is to move the dll reference out of the source code & into a make file (or similar) where it belongs.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lekalif |
| Posted: Fri Apr 25, 2008 5:32 am Post subject: |
|
|
Newbie
Joined: 21 Sep 2006
Posts: 5
|
The code is Centura SQLWindows. As far as I can tell, any external functional references (such as we're using for MQ) must be included in the main source file at build time.
As far as Make file...(I'm not a C/C++ programmer) I think maybe you're on to something. Do you mean create a custom .dll? (or equivalent library) and include that file in our main source file?
Clustering - sorry for not clarifying...Our customers are moving away from queue managers on Wintel machines and re-directing all Windows apps to their shared mq resource (MQ Cluster) hence the need for 'client-style' mq conn. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 25, 2008 5:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lekalif wrote: |
| The code is Centura SQLWindows. As far as I can tell, any external functional references (such as we're using for MQ) must be included in the main source file at build time. |
Ok, I've never heard of it never mind used it, so I'll let more experienced minds than mine comment on the truth of that.
| lekalif wrote: |
| As far as Make file...(I'm not a C/C++ programmer) I think maybe you're on to something. Do you mean create a custom .dll? (or equivalent library) and include that file in our main source file? |
No I don't. A make file (in simple terms) is a series of commands for building a given application. It's possible to write it in such a way that for a given flag it builds a client, for another (or in the absense of) a flag it builds a server. As I mentioned before, in C/C++ the source of the application is identical, it's how it's built that determines mode. The same is true of VB.
I don't see how a custom dll is going to help here - you're still left with the problem of determining what kind of calls to make at runtime. A custom dll with 2 identical sets of API embedded into it is going to make things worse not better.
The only thing that might work (see above re:I've no idea about your language) is if the source had a line FileInclude: placeholder.dll and whatever actually produces the executable could be wrapped in a script that did a find & replace before the build.
Ugly but workable perhaps. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Apr 26, 2008 12:33 pm Post subject: Re: How to determine what mq connectivity is being used? |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
| lekalif wrote: |
Hi all, has anyone ever encountered this challenge?
Source code uses mqm.dll to connect, perform browse,puts/gets etc.
We want to change this source to use Mqic32.dll (mq client)
Can anyone think of a way (from within the code or other?) to determine which connection is being used? Local (mqm.dll) or remote (mq client) |
Well, this is an odd request, as you usually know, before hand, what environment (binding or client) your application is going to reside in. Because things like 2-phase commits are different between the 2.
I've never heard of an application being deployed to multiple servers with different MQ configuration. It is just a recipe for disaster.
How are you going to determine if the queue manager is local or remote? A property file? If so, why don't you deploy the appropriate application and property file together?
Well, if you really need to go do this road then I would suggest dynamically loading either mqm.dll or mqic32.dll files. I have posted a sample code called NTLoadMQ here:
http://www.capitalware.biz/mq_code_c.html
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
