| Author |
Message
|
| pazy |
 Posted: Wed May 18, 2005 11:12 pm Post subject: Compiling API Exit on Solaris (xecU_S_LOAD_FAILED) |
 |
|
Novice
Joined: 13 Feb 2005
Posts: 12
|
I am using WebSphere MQ v5.3 and having a problem with my API Exit.
The Problem:
When trying to use an application which uses MQ Client(JMS), it cannot connect to the qmgr.
Providing the code along with error that it generated:
factoryPTP = new com.ibm.mq.jms.MQQueueConnectionFactory();
factoryPTP.setQueueManager(qmName);
factoryPTP.setTransportType(JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);
factoryPTP.setHostName(host);
factoryPTP.setChannel(channel);
factoryPTP.setPort(port);
factoryPTP.setClientId(uid);
connectionPTP = factoryPTP.createQueueConnection(uid,"nopw");
connectionPTP.start();
MQJMS2005:MQJMS2005: failed to create MQQueueManager for 'hostname
xxx:USUCSRV1'
MQJE001: An MQException occurred: Completion Code 2, Reason 2009
MQJE016: MQ queue manager closed channel immediately during connect
Closure reason = 2009
The error messages which appear in the WebSphere MQ errors file are:
----- amqzuax0.c : 829 --------------------------------------------------------
05/18/05 16:46:46
AMQ7216: An API Exit initialization function returned an error.
EXPLANATION:
The API Exit 'yyyyyy' function 'EntryPoint' in the module
'/var/mqm/exits/mq_exits' returned CompCode 2 and ReasonCode 2374.
ACTION:
Correct the problem with the API Exit 'yyyyy'
-------------------------------------------------------------------------------------
----- amqzuax0.c : 763 --------------------------------------------------------
05/18/05 16:47:40
AMQ7214: The module for API Exit 'yyyyy' could not be loaded.
EXPLANATION:
The module '/var/mqm/exits/mq_exits' for API Exit 'yyyyy' could
not be loaded for reason xecU_S_LOAD_FAILED.
ACTION:
Correct the problem with the API Exit module 'yyyyy'.
--------------------------------------------------------------------------------------
Details:
Server:
Solaris 8.0 (64-bit)
The WebShpere MQ version used in the server side:
> $ mqver
> Name: WebSphere MQ
> Version: 530.8 CSD08
> CMVC level: p530-08-L040921
> BuildType: IKAP - (Production)
Finding:
When performing simple activities (e.g. amqsput / amqsget), no errors appear.
When I tried to use the sample API Exit (-amqsaxe, supplied by IBM) the mentioned errors did not appear.
When I complied the code of the sample API Exit (supplied by IBM), the mentioned errors appear also for the compiled API Exit --> maybe it is a compilation problem.
My compilation script:
L0="-I../Headers "
C1="../Sources/mq_exits.c ../Sources/mq_logger.c "
C2="../Sources/dump.c ../Sources/simex.c"
O="mq_exits.o mq_logger.o dump.o simex.o"
S=mq_exits
export LIB=/opt/mqm/lib:.:$LIB
export PATH=/opt/SUNWspro/bin:$PATH
S1="/opt/SUNWspro/lib"
S2="/$OPENWINHOME/lib"
S3="../MQ/sun/lib"
export LD_LIBRARY_PATH=${S1}:${S2}:${S3}:$LD_LIBRARY_PATH
F1="-KPIC -mt "
F2="-L/opt/mqm/lib -dy -G -lmqmzf -lmqm -lmqmcs -lmqmzse"
cc $L0 -I../MQ/sun/include $F1 $C1 $C2 $F2 -c
ld -L$LIB -dy -G -lmqmzf $O -o ${OBJDIR}/${S}
I tried also (unsuccessfully), the compilation:
L0="-I../Headers "
C1="../Sources/mq_exits.c ../Sources/mq_logger.c "
C2="../Sources/dump.c ../Sources/simex.c"
O="mq_exits.o mq_logger.o dump.o simex.o"
S=mq_exits
export LIB=/opt/mqm/lib:.:$LIB
export PATH=/opt/SUNWspro/bin:$PATH
S1="/opt/SUNWspro/lib"
S2="/$OPENWINHOME/lib"
S3="../MQ/sun/lib"
export LD_LIBRARY_PATH=${S1}:${S2}:${S3}:$LD_LIBRARY_PATH
F1="-KPIC -mt "
F2="-L/opt/mqm/lib -dy -G -lmqmzf -lmqm -lmqmcs -lmqmzse"
cc $L0 -I../MQ/sun/include $F1 $C1 $C2 $F2 -c
ld -L$LIB -dy -G -lmqmzf -lmqm $O -o ${OBJDIR}/${S}
And also (unsuccessfully):
L0="-I../Headers "
C1="../Sources/mq_exits.c ../Sources/mq_logger.c "
C2="../Sources/dump.c ../Sources/simex.c"
O="mq_exits.o mq_logger.o dump.o simex.o"
S=mq_exits
export LIB=/opt/mqm/lib:.:$LIB
export PATH=/opt/SUNWspro/bin:$PATH
S1="/opt/SUNWspro/lib"
S2="/$OPENWINHOME/lib"
S3="../MQ/sun/lib"
export LD_LIBRARY_PATH=${S1}:${S2}:${S3}:$LD_LIBRARY_PATH
F1="-KPIC -mt "
cc $L0 -I../MQ/sun/include $F1 $C1 $C2 -c
ld -L$LIB -dy -G -lmqmzf -lmqm $O -o ${OBJDIR}/${S}
Thanks in advance!!!! |
|
| Back to top |
|
 |
| clindsey |
| Posted: Thu May 19, 2005 3:31 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
|
| Back to top |
|
|
| pazy |
| Posted: Thu May 19, 2005 3:36 am Post subject: |
|
|
Novice
Joined: 13 Feb 2005
Posts: 12
|
Thanks for your reply but I have already read it and tried the suggestion with no success....
 |
|
| Back to top |
|
|
| clindsey |
| Posted: Thu May 19, 2005 4:45 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
Which compiler are you using?
Try adding a -h parm on your link step.
For the sample amqsaxe, the entry point is EntryPoint, so you would specify -hEntryPoint. The entry point name may be different in your exit. It must match the name you set in the qm.ini file for
ApiexitLocal:
Function=xxxxx
Charlie |
|
| Back to top |
|
|
| pazy |
| Posted: Thu May 19, 2005 5:40 am Post subject: |
|
|
Novice
Joined: 13 Feb 2005
Posts: 12
|
I'm using /opt/SUNWspro/SC5.0/bin/cc.
Does the -h param has anything to do with this problem?
As far as I know, the -h param assigns a name to a shared dynamic library as a way to have different versions of a library.
Isn't it?
Thanks again! |
|
| Back to top |
|
|
| clindsey |
| Posted: Thu May 19, 2005 6:31 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
I thought -h added to entry point to the binary, but I rechecked the doc and that is not required on Solaris, so forget that suggestion.
This seems to be environment related, like the earlier post I referenced.
Try dumping the loader section of you compiled amqsaxe and compare to a dump of the supplied one. Compare the load paths.
You can also try 'ldd amqsaxe' on yours and the supplied one to see if it will tell you that a particular lib cannot be loaded.
Charlie |
|
| Back to top |
|
|
| pazy |
| Posted: Thu May 19, 2005 7:18 am Post subject: |
|
|
Novice
Joined: 13 Feb 2005
Posts: 12
|
Can you tell me how can I dump the loader section (dump with which option/s)?
In addition, I tried to find differences between the supplied amqsaxe exit and the one I have compiled and the only difference is the 'libmqmzse' library. Do you think it may cause the problem?
Thanks!!!  |
|
| Back to top |
|
|
| clindsey |
| Posted: Thu May 19, 2005 7:41 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
The only libs you need to link are libmqm and libmqmzf.
Sorry, I don't have access to a Solaris system right now.
On AIX, you can dump the loader section header with dump -Hv <name>.
I think Solaris only has -h to dump all the section headers. I guess you can do that and then look through the result to see the libpath info.
Did ldd give you any help?
Charlie |
|
| Back to top |
|
|
| pazy |
| Posted: Tue May 24, 2005 5:18 am Post subject: |
|
|
Novice
Joined: 13 Feb 2005
Posts: 12
|
The ldd command does not give any clue to the solution. The following are the outputs of the amqsaxe compiled by me (the first one) and by IBM:
> ldd amqsaxe
libmqmzf.so => /usr/lib/libmqmzf.so
libmqm.so => /usr/lib/libmqm.so
libmqmcs.so => /opt/mqm/lib/libmqmcs.so
libthread.so.1 => /usr/lib/libthread.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
librt.so.1 => /usr/lib/librt.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libmqmzse.so => /opt/mqm/lib/libmqmzse.so
libnsl.so.1 => /usr/lib/libnsl.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
> ldd /opt/mqm/samp/bin/amqsaxe
libmqm.so => /opt/mqm/lib/libmqm.so
libmqmcs.so => /opt/mqm/lib/libmqmcs.so
libmqmzse.so => /opt/mqm/lib/libmqmzse.so
libmqmzf.so => /opt/mqm/lib/libmqmzf.so
libthread.so.1 => /usr/lib/libthread.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libc.so.1 => /usr/lib/libc.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libdl.so.1 => /usr/lib/libdl.so.1
librt.so.1 => /usr/lib/librt.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libaio.so.1 => /usr/lib/libaio.so.1
/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
In addition, I have noticed that the mentioned errors appear only when connecting the queue manager remotely (by JMS or by using amqsgetc and amqsgetc commands). Can it be a problem related to the channel definitions?
Thanks |
|
| Back to top |
|
|
| clindsey |
| Posted: Tue May 24, 2005 6:26 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
I don't think it is a problem with the channel def. If it was, it would fail on the IBM supplied exit as well.
The load path bound to the exits must be different. There is something in the environment that is different, like LD_LIBRARY_PATH that allows it to work for local puts but not for remote puts. This most likely would be user related. Are you using runmqlsr as the listener? It is a setuid program that runs as the mqm user.
I would take an mq trace of both a local put and a remote put to see if it showed more detail around MQ's dlopen call. You may have to get IBM support to help you set up and read the trace.
One more thought. Just a guess but it is probably the path /usr/platform/SUNW,Ultra-60/lib/ that is causing the problem during the load. If so, you could add a link to libc_psr.so.1 in /usr/lib. Give that a try and if it doesn't help, then remove the link.
Charlie |
|
| Back to top |
|
|
| pazy |
| Posted: Wed Jun 01, 2005 12:56 am Post subject: |
|
|
Novice
Joined: 13 Feb 2005
Posts: 12
|
Runmqlsr is NOT used but the inetd daemon is used (amqcrsta and amqrmppa processes).
I have taken a mq trace while using the original amqsaxe file (supplied by IBM) the amqsaxe file compiled by me.
Here are the main results:
Original amqsaxe trace:
11:11:04.642700 29738.1 component:24 function:389 length:36 options:0 *pointer:25ac0
11:11:04.642712 29738.1 -------} xcsGetMem rc=OK
11:11:04.642723 29738.1 -------{ xcsGetMem
11:11:04.642739 29738.1 component:24 function:389 length:36 options:0 *pointer:25b10
11:11:04.642750 29738.1 -------} xcsGetMem rc=OK
11:11:04.642760 29738.1 ------} xstAttachSharedMemSet rc=OK
11:11:04.642770 29738.1 ------{ xcsReleaseThreadMutexSem
11:11:04.642782 29738.1 hmtx is 24b68
11:11:04.642792 29738.1 ------} xcsReleaseThreadMutexSem rc=OK
11:11:04.642809 29738.1 Connected Set 'PLUGSET' - () - 1::3::3-1228 rc(0) cc 1
11:11:04.642819 29738.1 -----} xcsConnectSharedMemSet rc=OK
11:11:04.642854 29738.1 -----{ xcsGetMem
11:11:04.642876 29738.1 component:33 function:96 length:2212 options:0 *pointer:3d2f8
11:11:04.642888 29738.1 -----} xcsGetMem rc=OK
11:11:04.642969 29738.1 Name:"SampleApiExit" Function:"EntryPoint" Module:"/app/mqm/samp/bin/amqsaxe" Data:" "
11:11:04.643012 29738.1 -----{ xcsLoadFunction
11:11:04.643056 29738.1 ObjectName(/app/mqm/samp/bin/amqsaxe) LoadType(262146)
11:11:04.654572 29738.1 Handle(FEF118E8) Function(fec828c4) Module(/app/mqm/samp/bin/amqsaxe)
11:11:04.654603 29738.1 -----} xcsLoadFunction rc=OK
My comiled trace file:
11:35:01.354276 1282.1 component:24 function:389 length:36 options:0 *pointer:376d0
11:35:01.354288 1282.1 ---------} xcsGetMem rc=OK
11:35:01.354299 1282.1 ---------{ xcsGetMem
11:35:01.354315 1282.1 component:24 function:389 length:36 options:0 *pointer:37720
11:35:01.354326 1282.1 ---------} xcsGetMem rc=OK
11:35:01.354336 1282.1 --------} xstAttachSharedMemSet rc=OK
11:35:01.354346 1282.1 --------{ xcsReleaseThreadMutexSem
11:35:01.354358 1282.1 hmtx is 357d0
11:35:01.354368 1282.1 --------} xcsReleaseThreadMutexSem rc=OK
11:35:01.354385 1282.1 Connected Set 'PLUGSET' - () - 1::3::3-1228 rc(0) cc 1
11:35:01.354395 1282.1 -------} xcsConnectSharedMemSet rc=OK
11:35:01.354431 1282.1 -------{ xcsGetMem
11:35:01.354451 1282.1 component:33 function:96 length:2212 options:0 *pointer:37770
11:35:01.354464 1282.1 -------} xcsGetMem rc=OK
11:35:01.354543 1282.1 Name:"SampleApiExit" Function:"EntryPoint" Module:"/app/mqm/samp/bin/amqsaxe" Data:" "
11:35:01.354580 1282.1 -------{ xcsLoadFunction
11:35:01.354626 1282.1 ObjectName(/app/mqm/samp/bin/amqsaxe) LoadType(262146)
11:35:01.355786 1282.1 Module(/app/mqm/samp/bin/amqsaxe) ErrorString(ld.so.1: /opt/mqm/bin/amqcrsta: fatal: libmqmzf.so: open failed: No such file or directory)
11:35:01.355817 1282.1 Handle(0) Function(0) Module(/app/mqm/samp/bin/amqsaxe)
11:35:01.355832 1282.1 -------}! xcsLoadFunction rc=xecU_S_LOAD_FAILED
11:35:01.355950 1282.1 -------{ xcsDisplayMessageForSubpool
11:35:01.355969 1282.1 --------{ xcsQueryValueForSubpool
11:35:01.355990 1282.1 --------} xcsQueryValueForSubpool rc=OK
11:35:01.356016 1282.1 --------{ xcsDisplayMessage
11:35:01.356078 1282.1 msgid:20007214 a1:20006175 a2:00000000 c1:SampleApiExit c2:/app/mqm/samp/bin/am c2:xecU_S_LOAD_FAILED
11:35:01.356095 1282.1 ---------{ xcsGetMem
11:35:01.356162 1282.1 component:23 function:22 length:6001 options:0 *pointer:38040
11:35:01.356179 1282.1 ---------} xcsGetMem rc=OK
Any ideas? (maybe the results of the ldd command may help ?- aforementioned)
Thanks. |
|
| Back to top |
|
|
| clindsey |
| Posted: Wed Jun 01, 2005 9:20 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
So it seems it cannot find libmqmzf.so when loaded by the amqcrsta process. Looking back at the ldd output, libmqmzf.so is found in /usr/lib in the first case and /opt/mqm/lib in the other case which I believe shows that the loader is relying on LD_LIBRARY_PATH to load your exit and this varies by user.
I recommend that you not reference LD_LIBRARY_PATH but rather set all the needed paths in the "-L" parm so the paths are bound to the exit. For example:
| Code: |
export LIB=.:/opt/mqm/lib:/opt/SUNWspro/lib:/$OPENWINHOME/lib:/usr/lib:/lib
.
.
.
ld -L$LIB -dy -G -lmqmzf -lmqm $O -o ${OBJDIR}/${S}
|
Charlie |
|
| Back to top |
|
|
| pazy |
| Posted: Sun Jul 03, 2005 6:03 am Post subject: |
|
|
Novice
Joined: 13 Feb 2005
Posts: 12
|
The problem was resolved !!!
Charlie, thank you so much !
The problem was as you expected:
From Sun documentation (http://docs.sun.com/app/docs/doc/805-6331/6j5vgg69j?a=view#devclds-26108):
SunOS release 4 linker search paths:
Link Editor: -L, LD_LIBRARY_PATH, /usr/lib, /usr/local/lib
Runtime Linker: LD_LIBRARY_PATH, -L, /usr/lib, /usr/local/lib
Solaris 7 linker search paths (with LD_LIBRARY_PATH=dirlist1):
Link Editor: -L, dirlist1, /usr/ccs/lib, /usr/lib
Runtime Linker: dirlist1, -R, /usr/lib
So as you can see, since Solaris 7, the runtime linker looks for the relevant libraries according to the -R values and NOT according to the -L values.
It causes my API exit to fail on my Solaris- the relevant libraries were not found on runtime (since they were looked for under LD_LIBRARY_PATH parameter (which was empty on the server) and under /usr/lib but NOT under /opt/mqm/lib !).
When Icompiled the API exit with -R parameter, it works !
--> The IBM documentation concerning API exit compilation on Solaris should be updated.
From:
Link the output from the compilation as a shared object:
ld -L$LIB -dy -G -lmqmzf <amqsaxe>.o -o <amqsaxe>
To:
Link the output from the compilation as a shared object:
ld -R$LIB -L$LIB -dy -G -lmqmzf <amqsaxe>.o -o <amqsaxe>
Thanks |
|
| Back to top |
|
|
|
|
