| Author |
Message
|
| reitidotnet |
 Posted: Mon Jul 23, 2012 5:13 am Post subject: MQ 7.1 (.net) entry point not found |
 |
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
Hi Guys - I hope anyone can give me a hint with my problem.
I currently try to migrate an .net application to MQ 7.1
The app was initially programmed with .net 1.1 and MQ 5.3 (amqmdnet.dll)
I now get the current MQ version (7.1) and changed all references. Everything works fine, BUT I get an EntryPointNotFoundException when calling GET on a queue.
It does say, that the Entry Point for zstMQGET in "......../mgic.dll" is not found.
I have requested the latest fix for MQ, maybe it will solve the problem, but maybe not. I've searched the whole web but was not able to find anything which relates to my problem.
May I have missed something? Even when using the "old" application (which works flawless) with an 7.1 installed MQ I get the same error.
Entry Point for zstMGGET not found in "..../mqic.dll" ..
I use Windows 7 64bit, app is .net 4.0, c#
I have tried to use the 32bit mq-dlls as well as the 64bit dlls, with the same result, that the entry point is not found. All paths are correct.
Any help is highly appreciated! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Jul 23, 2012 8:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I seem to remember seeing something about that.
Make the CCSID for the message retrieval 1208 and let us know how you fare... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| reitidotnet |
| Posted: Tue Jul 24, 2012 1:00 am Post subject: |
|
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
Thanks for your post. Unfortunately that has no impact. This Charset is already used everywhere.
Indeed, the above error is a EntryPointNotFoundException thrown by .Net Framework. So there is either a missing export or the declared function in the api or the call does not match the one in the library. (The later is true, I think)
I wonder, that I cannot find any information about that issue, so it seems there is already something fixed. I have to wait for the fixes, because I have no direct access to them and I have no idea IF it will fix that issue :-)
So maybe I missed something I have to care for when migrating a MQ 5.3 implementation... but it currently really seems, that the amqmdnet.dll has an error inside .. |
|
| Back to top |
|
|
| reitidotnet |
| Posted: Wed Jul 25, 2012 2:15 am Post subject: |
|
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
unfortunately the fixpack has not solved the problem (amqmdnet.dll is now 10x bigger ..?)
I still get the same error:
Entry Point "zstMQGET" was not found in DLL ".../mqic.dll" which is the message of an EntryPointNotFoundException
I am using this call:
| Code: |
| manager.AccessQueue(QUEUE_NAME,MQC.MQOO_INPUT_SHARED).Get(msg,msg_options); |
IF I remove the options parameter (IBM.WMQ.MQGetMessageOptions) the call succeeds. Investigating metadata from amqmdnet.dll, I am using this call:
| Code: |
| public void Get(MQMessage message, MQGetMessageOptions gmo); |
which seems to have no entry point in mqic.dll
..but I need to use MessageOptions. I also have checked back the latest MQ samples, and everything is equal, so I have no idea, what I could try more, to resolve my problem.
Any ideas?
edit: when using the 3-param Get Call (the one with maxmsgsize) it is also working - I may use that for now, but still wonder why that 2-param function has no entry point in mqic.dll, while it is used in the sampled all the time. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 25, 2012 4:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Do you get the same error if you use your procedure for building the samples?
Do you get the same error if you use the documented procedure for building the samples?
If you get either error, you should open a PMR. |
|
| Back to top |
|
|
| reitidotnet |
| Posted: Thu Jul 26, 2012 12:38 am Post subject: |
|
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
Just in case, someone stumbles upon this thread, I'll proceed posting my results.
I've found out, that the above behaviour only happens to one specific Queue. Later calls on differnent queues do not have any problem with entrypoints, so it is no static error.
I assume, that there happens some sort of late binding depending on some queue properties (which I do not know) - in my case, it is sufficient to specifiy the maxmessagesize in the get call to make it work.
While I do not know the exact reason for this behaviour, it is working for my case. |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Mon Jul 30, 2012 7:36 pm Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
There have been lot of changes to MQ .NET since MQ 5.3. With MQ v7.1 you have multi version installation where in more than one version of MQ can be installed on the same system.
The error you are getting is really strange. Have you uninstalled your earlier version of MQ properly and installed MQ v7.1? Looks like your application is referring to some older version libraries. |
|
| Back to top |
|
|
| reitidotnet |
| Posted: Tue Jul 31, 2012 12:11 am Post subject: |
|
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
I have setup MQ 7.1 on a clean machine.
The app also uses multiple queues and the problem does only occur on one of them, so it seems not to be a static "linking" problem with some dlls.
In code there is no difference in creating or accessing the queue objects, so it looks like it depends on the queue itself somehow. For whatever reason I have to use the 3-param call of MQGET on this one queue.
But I am just guessing on this one - using the 3-param-call just works fine; everywhere else in the app the normal calls work. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 31, 2012 4:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The only way that any behavior in MQ is different for a specific queue versus other queues on the same queue manager is if a) the queue is damaged, b) the settings on the queue are different.
Either way, you need to take this problem to your MQ administrator - whom you should have been talking to from the start anyway - and provide firm evidence to them that it works this way for exactly one queue.
And make sure you can recreate it with a different application. |
|
| Back to top |
|
|
| reitidotnet |
| Posted: Tue Jul 31, 2012 4:53 am Post subject: |
|
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
Yes the queue settings are different (server side) for sure, but I don't know and it is not possible to change anything because of backwards compatibility.
I solved the problem on the clientside by using another function call - even when I do not know the exact reason, I am fine with that at the moment and cannot efford spending too much time with MQ admins ;-) .. they will not change anything until absolutely needed because the project is critical (remember murphies law)
But thank you for your efforts - hopefully someone find this thread useful, when being in a similar situation. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 31, 2012 4:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| reitidotnet wrote: |
Yes the queue settings are different (server side) for sure, but I don't know and it is not possible to change anything because of backwards compatibility.
I solved the problem on the clientside by using another function call - even when I do not know the exact reason, I am fine with that at the moment and cannot efford spending too much time with MQ admins  .. they will not change anything until absolutely needed because the project is critical (remember murphies law)
But thank you for your efforts - hopefully someone find this thread useful, when being in a similar situation. |
If it's a critical project, it's critical that you don't leave unresolved issues with it hanging around. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 31, 2012 5:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| reitidotnet wrote: |
Yes the queue settings are different (server side) for sure, but I don't know and it is not possible to change anything because of backwards compatibility.
I solved the problem on the clientside by using another function call - even when I do not know the exact reason, I am fine with that at the moment and cannot efford spending too much time with MQ admins .. they will not change anything until absolutely needed because the project is critical (remember murphies law)
But thank you for your efforts - hopefully someone find this thread useful, when being in a similar situation. |
If it's a critical project, it's critical that you don't leave unresolved issues with it hanging around. |
If you don't know why this specific queue reacts the way it does, you can't be sure a different queue won't react that way in a different environment when you promote your code forward. Or that one day the admins will change something in this environment and you'll hit the same problem.
There's also the question of documentation; how will you explain that you're using that specific and unexpected function call on this specific queue? You'd never get "because if I don't use this call the magic goes away" past me in a document review.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| reitidotnet |
| Posted: Tue Jul 31, 2012 5:21 am Post subject: |
|
|
Novice
Joined: 23 Jul 2012
Posts: 10
|
Please do not start an offtopic discussion about fundamentals - the project is live and it is crucial to maintain it running all the time without any risks.
The client is upgraded to latest compiler and MQ and the old version STILL needs to run as always - so there will be no change in server side mechanics for now - at least it is not my decision.
The problem is communicated and it is not my job to say "it does not work" - my job is to make it work as long as that's possible.
In my case (described in that thread) I just have no time to spent hours of work investigating a problem (or forcing people to investigate hours of work into mq-settings from stoneage) which does not concern me any more and may be just a bug which will not be fixed before end of time forcing me to do the "magic" anyway. If the magic fails in later testing, I can still investigate like Sherlock and start chasing ghost flies ;-) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jul 31, 2012 5:50 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| reitidotnet wrote: |
Please do not start an offtopic discussion about fundamentals - the project is live and it is crucial to maintain it running all the time without any risks.
... so there will be no change in server side mechanics for now - at least it is not my decision.
... it is not my job to say "it does not work" - my job is to make it work as long as that's possible.
... I just have no time to spent hours of work investigating a problem (or forcing people to investigate hours of work into mq-settings from stoneage) which does not concern me any more and may be just a bug which will not be fixed before end of time forcing me to do the "magic" anyway. If the magic fails in later testing, I can still investigate like Sherlock and start chasing ghost flies |
Your frustration is noted. However, problem-determination (problem source identification) takes whatever time and effort it takes. There is no fast-path to a fix, as you are discovering.
We are a free service staffed by volunteers. I'd guess that many/most of us don't have v5.3 and .net skills.
If this is mission-critical for your organization, it may be time to bring a paid expert on-site.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| drikel |
| Posted: Mon Aug 27, 2012 2:42 am Post subject: |
|
|
Newbie
Joined: 27 Aug 2012
Posts: 4
Location: Brussels
|
Dear,
I stumbled upon the same issue while migrating my code from MQ 7.0 to MQ 7.1.0.1.
After fiddling around with the samples (SimpleGet), I succeeded to reproduce the error.
The root cause comes from the properties MQC.TRANSPORT_PROPERTY that you must specify for the MQQueueManager's constructor object.
In the sample it is set to MQC.TRANSPORT_MQSERIES_MANAGED. If you switch it to MQC.TRANSPORT_MQSERIES_CLIENT, which is the value that is most probably set in your MQ 5.3 code, you'll reproduce the exact same behaviour (same exception, if you add the 3rd parameters it works again, etc.)
If possible, change this parameter and hopefully it will work.
In my case it is a little bit more difficult as this parameter is set up via an XML file which is distributed and used by a Java version of the same API (long story).
I'll write a PMR and post the result when I'll have an answer. |
|
| Back to top |
|
|
|
|
