>Yes for windows at least. >However you can only do one at a time. You do it by building a dll hook, >basically you put your own library between the application and MQ with your >library loading the client or server dll as required.
>HOWEVER you will be building something with custom code you are may have to >modify every time you upgrade MQ. A risky business. But techincally >challenging and fun to do. >Regards >Tim A Tim, What you say is true if you wanted to use a dll hook but that seems a restrictive way of going about it to me. On Windows it is trivial to use LoadLibrary() and then GetProcAddress() to access the MQI calls as function pointers. You can wrap these up in macros to make it seem to the calling program as though you're calling the MQI directly. Using this method it is easily possible to have both locally connected connections and client connections in the same process. (This is the method I use in my MO71 Administrator program). The code was basically used to construct SupportPac MA74 which allows you to link with a DLL which will autodetect for you but only on Windows. However, if memory serves, the Support Pac also restricts you to running either in local or client mode. Not both at the same time. You can do the same type of thing on Unix. Dynamically load shared library, query the procedure addresses and wrap with macros. I do that inside the product code but I've never done it for the MQI library itself. Hope this helps, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
