| Author |
Message
|
| reitidotnet |
 Posted: Mon Aug 27, 2012 2:55 am Post subject: |
 |
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
Thanks for your response. Actually I've tried that before with the result, that I got a "Host Not Found" back from MQ
So the Transport is set to CLIENT in my case
Are there any drawbacks to use the 3rd-paramter version? I cannot think of any. ..and it still does not occur on different queues in the same application using the same manager.
As I said before: I am fine with the 3param call which I only need on 1 queue (only called once at program start so nothing exciting) |
|
| Back to top |
|
 |
| drikel |
| Posted: Mon Aug 27, 2012 3:13 am Post subject: |
|
|
Newbie
Joined: 27 Aug 2012
Posts: 4
Location: Brussels
|
Using the 3rd parameters implies probably a little performance issue as the MQ API is probably doing several if statements. Depends also on the value of the parameter you have set up (what if the application is sending in the future huge messages with a size > to the value of the parameter => it might endanger your application and you never know what the future will look like)
CLIENT means also that your application is not ".Net managed". Maybe something you might want to analyze...
Could be also that your application is compiled into 32bits, or at least using the 32 bits dll of MQ which might (or not) cause trouble or performance impact on a 64 bits machine (I say this because I encounter such problem on a Windows 2008 Server with IIS 7.5 in 64 bits).
Just my 2 cents...
_________________
It all starts when you know what you want. |
|
| Back to top |
|
|
| reitidotnet |
| Posted: Mon Aug 27, 2012 3:21 am Post subject: |
|
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
I've tried compiling different versions because MQ does internally link to different DLLs but it has not solved the issue.
The queue where this problem occurs is not very important nor transports big chunks of data .. actually it only delivers queue names which are used later on and is dismissed after that. It may be investigated later on in more detail why it is only this queue making the "problem"
Thanks for your informations |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 27, 2012 4:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The main difference between a MANAGED connection and a CLIENT connection is that a MANAGED connection doesn't use the mqic.dll. It uses a pure tcp/ip implementation of the MQ client protocol written directly in .NET code rather than the implementation packaged in mqic.dll.
So that's the reason that this stops any linking errors against mqic.dll - it stops linking anything against mqic.dll at all.
It remains an issue of concern that code has to be changed depending on what queue is being addressed. Without understanding the cause behind this, it remains possible that any queue could suddenly need this change at any moment - almost certainly at the most application-critical moment. |
|
| Back to top |
|
|
| drikel |
| Posted: Mon Aug 27, 2012 4:20 am Post subject: |
|
|
Newbie
Joined: 27 Aug 2012
Posts: 4
Location: Brussels
|
The problem is that the backward compatibility is somehow broken which is definitely not good 
PMR has been open 
_________________
It all starts when you know what you want. |
|
| Back to top |
|
|
| reitidotnet |
| Posted: Fri Oct 05, 2012 2:02 am Post subject: SOLVED |
|
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
Hi Guys
After havig another problem with the queue not reporting anything at all I was still trying to solve my EntryPoint Error.
And yes, I've found the Solution for it! Problem was, for that one specific Queue I was using a MessageOptions Object to tell MQ to wait for a Message Arrival on their own (instead of getting as long as 2033 is reported like I do on the other queues).
I've found out, that I use (for whatever reason, may be a old bit of code) MQGMO_CONVERT in the MessageOptions and that single option seems to lead to a different runtime-linking of the get function (somewhere inside) which is then not found in mqic.dll.
So, the problem was solved by removing this specific MessageOption-Option.
I do not know, why this is there, because generally the converting is done seperately, so that may be really some very old bit of code, which was never thought about.
Hopefully, that will help someone in the future |
|
| Back to top |
|
|
| drikel |
| Posted: Fri Oct 05, 2012 4:17 am Post subject: |
|
|
Newbie
Joined: 27 Aug 2012
Posts: 4
Location: Brussels
|
Gentlemen,
IBM created the APAR IC86548 to fix this problem for MQ 7.0 and 7.1.
I suppose it will be released for the next CSD :
Fix Pack 7.1.0.2 4Q 2012 UNIX, Windows and IBM i
Fix Pack 7.0.1.10 1Q 2013 UNIX, Windows and i5/OS
You could maybe request the fix if needed urgently.
Regards.
_________________
It all starts when you know what you want. |
|
| Back to top |
|
|
|
|
