We have an old ASP application that uses a home grown COM object wrapper written in VB6 to communicate with an MQ server.
The app was running fine on a Win2000 server using MQ client v5.x
Somebody decided that server needed to be upgraded to Win2008...and the app stopped working.
Given that the v5 client isn't supported on Win2008, we installed the latest v7.5 client...
But we're seeing a MQICSTD.DLL not found error...
Looking at the source for the VB6 app, it appears all the MQ calls are defined like so...
Declare Sub MQCONN Lib "MQICSTD.DLL" (ByVal QMgrName As String, Hconn As Long, CompCode As Long, Reason As Long)
I found a couple pages on the internet that mention MQICSTD.DLL, but no real good explanation...
It appears as if at some point IBM may have changed the MQ client DLL name??? Can anybody confirm that?
Is there anyway to deal with this issue other than modifying the VB6 app to point to the correct DLL?
Pinned topic Old app getting a MQICSTD.DLL not found error with new client
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-02-19T02:51:38Z at 2013-02-19T02:51:38Z by SystemAdmin
SystemAdmin 110000D4XK8523 Posts
Re: Old app getting a MQICSTD.DLL not found error with new client2013-02-19T02:51:38ZThis is the accepted answer. This is the accepted answer.VB apps should include the relevant cmqb.bas code module for the version of VB and MQ.
For a normal client it contains the code:
Declare Sub MQCONN Lib "MQIC.DLL" Alias "MQCONNstd@16" _
(ByVal QMgrName As String, _
Hconn As Long, _
CompCode As Long, _
Reason As Long)
The VB6 app code should not have any hard-coded Declare Sub or Global Const for the MQI, these are all in cmqb.bas.
IBM can change the DLL file names and DLL entry points at any time. They are not documented in the WMQ Infocenters. Apps should not be using these directly. The only safe practice is to always use the IBM supplied header files / code modules.