| Author |
Message
|
| sbenilan |
 Posted: Mon Nov 16, 2009 6:25 am Post subject: dynamically load MQI library in C++ under MVS/USS |
 |
|
Newbie
Joined: 16 Nov 2009
Posts: 6
|
Hi,
I'm new here.
I'm porting a C++ application that already runs properly under most unixes and win32. This application plugs MQI library at runtime instead of link time such that the binary executable is compatible with MQClient and MQServer such as multiple versions of MQI.
I'm using Unix System Service to port the application on z/OS. I must admit that I'm not an expert at all in MVS environment, so my assumptions are only assumptions...
I'm figuring that it is possible to follow the same strategy as for UNIX, that is relying on dlopen/dlsym interface to dynamically plug MQ library (shared object/DLL) to my application, versus link time using provided side-decks as it is advised in the docs I could read.
The program compiles fine, however I have runtime issue when trying to dlopen the MQI library. My understanding is that the MQI library (or DLL) is located in an MVS dataset and that dlopen use a particular syntax to refer a file in a dataset (using // prefix).
Either it's not possible, or I'm missing the proper name of the MQI library file. So if someone already succeeded to do that I'd be glad to have advices/samples on how to properly achieve that.
Thank you,
sylvain |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Nov 16, 2009 7:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| sbenilan |
| Posted: Mon Nov 16, 2009 7:25 am Post subject: |
|
|
Newbie
Joined: 16 Nov 2009
Posts: 6
|
Thank you bruce,
I have no issue with the code itself, nor with dlopen (or the obsolete dllload) facility loading DLLs in general, it works like a charm with other DLL even on z/OS.
It is really about MQI DLL under z/OS, and according to my reading this DLL resides in an MVS dataset.
In fact I believe I only miss the proper name of that DLL... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 16, 2009 7:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
WMQ for z/OS resides in MVS datasets.
Look at page 235 of the z/OS XL C/C++User’s Guide: http://publibz.boulder.ibm.com/epubs/pdf/cbcug160.pdf
_________________
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 |
|
|
| sbenilan |
| Posted: Mon Nov 16, 2009 8:12 am Post subject: |
|
|
Newbie
Joined: 16 Nov 2009
Posts: 6
|
Hi again bruce,
That's kind of you but I'm not sure I get your point here. Page 235 is about TEMPLATEREGISTRY | NOTEMPLATEREGISTRY !? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Nov 16, 2009 9:35 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Nov 16, 2009 2:55 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| sbenilan wrote: |
Thank you bruce,
I have no issue with the code itself, nor with dlopen (or the obsolete dllload) facility loading DLLs in general, it works like a charm with other DLL even on z/OS.
It is really about MQI DLL under z/OS, and according to my reading this DLL resides in an MVS dataset.
In fact I believe I only miss the proper name of that DLL... |
It might be something like
| Code: |
| //'sys1.mqm.scsqc370' |
the prefix will depend on where MQ is installed.
_________________
Glenn |
|
| Back to top |
|
|
| sbenilan |
| Posted: Wed Nov 18, 2009 10:54 am Post subject: MQCONNX OK, MQOPEN -> 2018 |
|
|
Newbie
Joined: 16 Nov 2009
Posts: 6
|
I Glenn,
Thanks for your anwser. I still had problem and started to think that it is probably the wrong way of linking to MQI.
I changed the code and now rely on fetch("CSQBCONX") instead of trying to dynamically load an MQI dll I can't find...
But I now face an other issue, my call MQCONNX is successful the handle returned looks good but MQOPEN fails with reason code 2018 (MQRC_HCONN_ERROR). This sequence of code use to work fine on other OSes.
I don't known if using fetch in a C++ program can be the cause of the issue. I don't known either if running the program from within USS can be the cause of the problem or not.
well, it starts to be a bit frustrating  so any help on this would be greatly appreciated.
thanks anyway. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 18, 2009 11:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I'd strongly recommend that you refer to the WMQ Application Programming Guide. There's a section on building apps on z/OS. Follow the instructions, with sample JCL.
MQI calls are platform-neutral; however, o/s operations are very different.
_________________
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 |
|
|
| gbaddeley |
| Posted: Wed Nov 18, 2009 2:24 pm Post subject: Re: MQCONNX OK, MQOPEN -> 2018 |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| sbenilan wrote: |
I Glenn,
Thanks for your anwser. I still had problem and started to think that it is probably the wrong way of linking to MQI.
I changed the code and now rely on fetch("CSQBCONX") instead of trying to dynamically load an MQI dll I can't find...
But I now face an other issue, my call MQCONNX is successful the handle returned looks good but MQOPEN fails with reason code 2018 (MQRC_HCONN_ERROR). This sequence of code use to work fine on other OSes.
I don't known if using fetch in a C++ program can be the cause of the issue. I don't known either if running the program from within USS can be the cause of the problem or not.
well, it starts to be a bit frustrating so any help on this would be greatly appreciated.
thanks anyway. |
Why are you using MQCONNX rather than MQCONN? MQ Client is not supported on USS.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 18, 2009 3:20 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| MQ Client is not supported on USS. |
More broadly, WMQ on z/OS can only be an MQ server, not an MQ client. (Java being the exception to nearly every rule.)
Much has been posted here referring to 'the mvs side' or 'the uss side'. They are one and the same. You can compile and link (bind) to either an MVS dataset or down the USS UNIX filepath. Once bound, the executable can be invoked from UNIX or MVS shells.
For those unfamiliar with USS on z, you don't boot UNIX; rather, it's just there - part of the MVS base.
_________________
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 |
|
|
| sbenilan |
| Posted: Thu Nov 19, 2009 3:04 am Post subject: |
|
|
Newbie
Joined: 16 Nov 2009
Posts: 6
|
Hi all,
Thank you all for your help. Just wanted to leave a note in case someone else face the same issue.
I came up with a solution. Apparently the good way to do is to write a tiny DLL module in C that is linked with the supplied MQ stub program (for batch it is thlqual.SCSQLOAD(CSQBSTUB)), that C DLL exposes an encapsulated MQI API in its exported symbol table. The C++ program can then dynamically (dlopen/dlsym) load that DLL and get access to MQI via the DLL interface.
In my previous attempt I probably faced a linkage issue which depends on compiler options (especially XPLINK) and the language itself (C vs C++). Which is my explanation of the MQRC_HCONN_ERROR issue... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 19, 2009 6:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Congrats on a good technical solution. There are, however, potential performance issues (even on a mainframe) regarding dynamic vs. static linking of called modules.
It's a trade-off between flexibility and operating system overhead.
_________________
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 |
|
|
| sbenilan |
| Posted: Thu Nov 19, 2009 7:42 am Post subject: |
|
|
Newbie
Joined: 16 Nov 2009
Posts: 6
|
Sure bruce,
I feel OK with the dynamic overhead. I'm much more concerned by flexibility, meaning that the app is highly portable, some module do not need to run any OS nor rely on a particular third party application version (like MQ 5/6/7 or even Oracle 8/9/10/11) which is a huge time saver in term of maintenance. In case of real performance issue, I can run multiple instance of the process...
The thing I learned during that long test/fail/retest is that IBM provide for z/OS a C++ object oriented API for MQ (with special headers and side decks) but not for the standard MQI which remains C (or COBOL, or assembler) oriented, if you want to use MQI from a C++ code then the solution decribed above is I believe the good way. This is unfortunately what lost me at the first time because that C API is widely supported on unix or win32.
Last, just because it has been highlighted previously in this thread, I confirm that it works pretty well on USS side... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 19, 2009 8:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| meaning that the app is highly portable, |
The UNIX definition of portability is at source-code level, not runtime; and MQI calls are portable.
Your inclusion of dll-type calls (LOAD, LINK are equivalents o/s-level calls on MVS) makes your app somewhat portable. If your business requirement was portability, you are close.
Again, my compliments to you on a good technical solution.
_________________
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 |
|
|
|
|
