# Unsatisfied code symbol 'SMP\_V213' in load module **URL:** \ **Category:** Forum\ **Tags:** Adabas-Natural, Adabas, Adabas-on-Windows-UNIX, Adabas-on-Linux, Adabas-Installation-and-Setup-on-Open-Systems\ **Created:** [December 30, 2005, 10:10pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845 "2005-12-30T22:10:17Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Robert\_E\_Bevis](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Robert\_E\_Bevis](https://techcommunity.softwareag.com/u/Robert_E_Bevis)\ **Post date:** [December 30, 2005, 10:10pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/1 "2005-12-30T22:10:17Z")
Since I’ve installed ADABAS 5 on my HP-UX 11.23 (11i Rel.2) PA-RISC 64-bit server, I’ve been seeing this message all over the place: /usr/lib/pa20\_64/dld.sl: Unsatisfied code symbol ‘SMP\_V213’ in load module ‘/sag/ada/v51103/lib/libadacom.sl’. The last portion varies based on what utility I’m using: …/bin/adainv.bin, …/bin/adanuc.bin, …/bin/adabck.bin, …/bin/adaopr.bin, etc. But not consistantly. I’ve check the version of the /sag/common/lib/libsagsm2.sl, which is 2.13.1, and adawrp is adding the $ADADIR/$ADAVERS/lib to the SHLIB\_PATH environment variable. I’m not sure what else to check, but something must not be correct or define correctly. Any help would be appreciated. Robert ---
**Author:** ![Robert\_E\_Bevis](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Robert\_E\_Bevis](https://techcommunity.softwareag.com/u/Robert_E_Bevis)\ **Post date:** [December 30, 2005, 10:25pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/2 "2005-12-30T22:25:35Z")
Of course, after I post my previous message, I need to add that I am also running ENTIRE NET-WORK v722 and the SAG Directory Server which both have their own version of libsagsmp2.sl, which is v2.9.1. Could these two versions of libsagsmp2.sl be in conflict? Should I replace the older versions of libsagsmp2.sl in the WCP and ADI directories? What affect will this have on these products? Again, any assistance would be greatly appreciated. Robert ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [December 31, 2005, 12:02am UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/3 "2005-12-31T00:02:12Z")
Did you try running this based on a sagenv script without WCP and ADI, do the messages go away ? This way you’d be sure if one of these is getting in the way. Additionally you might want to check if LD\_LIBRARY\_PATH or LD\_LIBRARY\_PATH64 interfere with SHLIB\_PATH ---
**Author:** ![Robert\_E\_Bevis](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Robert\_E\_Bevis](https://techcommunity.softwareag.com/u/Robert_E_Bevis)\ **Post date:** [December 31, 2005, 1:14am UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/4 "2005-12-31T01:14:55Z")
LD\_LIBRARY\_PATH64 is not really used any more and is not presently set. LD\_LIBRARY\_PATH is used only by ENTIRE ACCESS and is set to ‘/sag/osx/v5311/bin’ and nothing more. I have not tried removing the ADI and WCP environment settings from the /sag/sagenv file. Their version of libsagsmp2.sl is definately not in the path before the ADABAS version, so the newer version of libsagsmp2.sl should be found first. However WCP and ADI are currently active on this server. I was wondering if there could be a problem with ADABAS using its own version of libsagsmp2.sl if the WCP or ADI version is currently active? In order to do a proper test, besides removing the WCP and ADI environment settings, I would also want to shut them down. What do you think? ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [December 31, 2005, 1:25am UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/5 "2005-12-31T01:25:35Z")
Just copy sagenv.new (or whatever you are using instead) to something else and just keep sagbaseenv and adaenv, then logout, login again, execute the newly created script (which only works when you don’t call sagenv from .profile, of course), just to make sure no other envvars are set. Then start adaopr and see if the messages are gone. This won’t affect ADI or WCP, you won’t have to shut it down either. ---
**Author:** ![Robert\_E\_Bevis](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Robert\_E\_Bevis](https://techcommunity.softwareag.com/u/Robert_E_Bevis)\ **Post date:** [December 31, 2005, 1:28am UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/6 "2005-12-31T01:28:19Z")
I left WCP and ADI running and just commented them out from the sagenv. This seems to have resolved the problem. I don’t think it’s the SHLIB\_PATH or the LD\_LIBRARY\_PATH. I think it’s PATH. Both ADI and WCP add their own directories to the PATH where the older version of libsagsmp2.sl can be found. Do ADI and WCP support the newer version of the libsagsmp2.sl? ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [December 31, 2005, 1:42am UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/7 "2005-12-31T01:42:45Z")
O.k., that’s what I expected, so far, so good 😉 I don’t expect any compatibility issues with the newer libsagsmp2 for WCP and ADI, but I’d have to test to tell for sure. What I’d do is putting WCP and ADI behind basetech & ADABAS in your sagenv, this way libsagsmp2 from ADA will appear in the PATH first. ---
**Author:** ![Robert\_E\_Bevis](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Robert\_E\_Bevis](https://techcommunity.softwareag.com/u/Robert_E_Bevis)\ **Post date:** [December 31, 2005, 2:19am UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/8 "2005-12-31T02:19:44Z")
The order of the sagenv is the base tech, ADI, ADA and then WCP. I don’t think the order in the sagenv matters because ADA inserts itself at the beginning of the PATH, where ADI and WCP append themselves to the end of the PATH. The problem is that ADABAS only inserts $ADADIR/$ADAVERS and $ADADIR/$ADAVERS/tools to the beginning of the PATH. It doesn’t insert $ADADIR/$ADAVERS/lib where the new version of libsagsmp2.sl is found. The same holds true for the base technology. It inserts its bin directories to the beginning of the PATH, but not its library directory where the new version of libsagsmp2.sl (installed by ADABAS 5) is found. Seems strange that ADABAS is searching the PATH for a shared library before it searches SHLIB\_PATH, but that’s what it appears to be doing. I can manually add $ADADIR/$ADAVERS/lib to the PATH, but until we know what affect the new version of the libsagsmp2.sl will have on ADI and WCP, I rather not chance it. Can you find out if the new version of libsagsmp2.sl is compatible with ADI and WCP? Thanks! ---
**Author:** ![anon98178625](https://avatars.discourse-cdn.com/v4/letter/a/858c86/32.png) [@anon98178625](https://techcommunity.softwareag.com/u/anon98178625)\ **Post date:** [January 16, 2006, 5:33pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/9 "2006-01-16T17:33:07Z")
Hello all, ADABAS v5.1 does provide some changes in LD\_LIBRARY\_PATH handling with ADABAS utlities under Unix. All ADABAS utility relevant libraries are wrapped via wrapper script. Please never use .bin (like adanuc.bin) executables directly. If your installation was succeed, a link have to be set from $ADADIR/$ADAVERS/adanuc to $ADADIR/$ADAVERS/bin/adawrp adawrp is a wrapper script, which set LD\_LIBRARY\_PATH correctly. You must use $ADADIR/$ADAVERS/adanuc to start ADABAS or respectivly use other ADABAS utility. adanuc.bin is definitly incorrect. The wrapper script should provide LD\_LIBRARY\_PATH information for you. When this link is not set correctly after installation, please contact ADABAS support to analyze this faulty. Bye, Thorsten ---
**Author:** ![Robert\_E\_Bevis](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Robert\_E\_Bevis](https://techcommunity.softwareag.com/u/Robert_E_Bevis)\ **Post date:** [January 16, 2006, 9:09pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/10 "2006-01-16T21:09:47Z")
Thorsten, That sounds good in theory, but doesn’t work in reality. the unresolved symbol ha nothing to do with the ADABAS Wrapper, but with the difference is versions of libsagsmp2.sl shared by ADABAS, ENTIRE NET-WORK (WCP) and the SAG Directory Server (ADI). While the ADABAS Wrapper may insert the $ADADIR/$ADAVERS/lib at the beginning of the LD\_LIBRRAY\_PATH, it does nothing for the fact that the older version of libsagsmp2.sl used by WCP and ADI have been previously defined to the PATH. Unlike ADABAS, ADI and WCP don’t have separate sub-directories for shared libraries and binaries. Both are stored together and both are placed in the PATH. And the mechanism loading a shared library searches the PATH before searching the LD\_LIBRARY\_PATH. To corrected this problem it was recommended to me by development, to replace the libsagsmp2.sl files in the ADI and WCP subdirectories with the newer version provided by ADABAS. This way, the correct version of the libsagsmp2.sl would found, regardless of the wrapper, or the PATH or the LD\_LIBRARY\_PATH. So much for the the wrapper. The ADABAS wrapper is an interesting concept, but doesn’t really work as long as it operates in a vacuum without consideration of other SAG products that may be installed and operational. Working in a vacuum without regards to other SAG products seems to be the reality that all the product development groups seem to be working in these days. I can say this having spent that last 3 months with SAG personnel on-site, the Support Center and Development all trying to get ADABAS, ENTIRE X Communicator, ENTIRE NET-WORK, NATURAL and the Base Technology all working together on a single server. All I can say is that it has been a nightmare. Robert ---
**Author:** ![anon98178625](https://avatars.discourse-cdn.com/v4/letter/a/858c86/32.png) [@anon98178625](https://techcommunity.softwareag.com/u/anon98178625)\ **Post date:** [January 17, 2006, 2:01pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/11 "2006-01-17T14:01:47Z")
Hi, your are on HP-UX, is that right? Dynamic libraries are searched in LD\_LIBRARY\_PATH and then in SHLIB\_PATH on HP-UX systems. On 32Bit HP-UX only SHLIB\_PATH is used. PATH is never used to search for dynamic libraries on Unix systems. On Windows Systems PATH is used to load dlls. The wrapper script works well on all HP-UX systems here. Even with ADABAS and ADI installed on same $SAG environment. Can you please specify your configuration why PATH or LD\_LIBRARY\_PATH is not set correctly to the right location. There must be anything wrong, because in normal case the wrapper script works and/or $SAG/common/lib is fallback path to search for libraries and here the newest version should be stored with any Software AG installation. Bye, Thorsten ---
**Author:** ![anon98178625](https://avatars.discourse-cdn.com/v4/letter/a/858c86/32.png) [@anon98178625](https://techcommunity.softwareag.com/u/anon98178625)\ **Post date:** [January 17, 2006, 4:59pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/12 "2006-01-17T16:59:58Z")
Hi, after some rethinking and testing with adawrp I found the problem your and perhaps other environment have. ADABAS adawrp wrapper does only set SHLIB\_PATH. But HP-UX does look in LD\_LIBRARY\_PATH first and then in SHLIB\_PATH. If you have set LD\_LIBRARY\_PATH to an path having libsagsmp2.sl, this library was taken first. You can add a line to adawrp and then it would run with wrapper: HP-UX) LD\_LIBRARY\_PATH=“$ADALIB${LD\_LIBRARY\_PATH:+”:“}${LD\_LIBRARY\_PATH:-}” SHLIB\_PATH=“$ADALIB${SHLIB\_PATH:+”:“}${SHLIB\_PATH:-}” export SHLIB\_PATH ;; Bye, Thorsten ---
**Author:** ![Robert\_E\_Bevis](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Robert\_E\_Bevis](https://techcommunity.softwareag.com/u/Robert_E_Bevis)\ **Post date:** [January 17, 2006, 9:03pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/13 "2006-01-17T21:03:53Z")
Thorsten, Other than we are HP-UX 11.23 64-bit PA-RISC, I’m not sure what I can tell you, but even with the wrapper the wrong version of the libsagsmp2.sl was found. Neither ADI nor WCP add themselves to either LD\_LIBRARY\_PATH or SHLIB\_PATH, but only to PATH. If there is a way to configure how shared libraries are searched for I don’t know how. Given the error messages I would receive like this one below, I can see that the ADABAS 5 library is being searched. /usr/lib/pa20\_64/dld.sl: Unsatisfied code symbol ‘SMP\_V213’ in load module ‘/sag/ada/v51103/lib/libadacom.sl’. However, if the ‘/sag/ada/v51103/lib/libsagsmp2.sl’ had been loaded, then the ‘SMP\_V213’ code symbol would have been resolved. By the error messages, it obviously was not. I checked both the ‘/sag/ada/v51103/lib/libadasmp2.sl’ and the ‘/sag/common/lib/libsagsmp2.sl’ and both were the correct version which includes the ‘SMP\_V213’ code symbol. There were only two other copies of the ‘libsagsmp2.sl’ installed on the server. They were both older versions that did not include the code symbol ‘SMP\_V213’ and were located in ‘/sag/adi/libsagsmp2.sl’ and ‘/sag/wcp/v722/libsagsmp2.sl’. Neither defined to LD\_LIBRARY\_PATH nor SHLIB\_PATH. Both defined to PATH. And both products are currently active. My initial thoughts were that because these products were currently active and their version of the ‘libsagsmp2.sl’ already loaded that the ADABAS 5 version wasn’t reloaded when called, but development rejected this idea. If I shutdown both ADI and WCP the errors continued with ADABAS. If I removed both ADI and WCP from the path, the errors went away. If I put either ADI or WCP back into the PATH the errors returned. Clearly this is an environmental issue and PATH is being searched before LD\_LIBRARY\_PATH and SHLIB\_PATH. I don’t know how to change the search order for shared libraries and developments only advice was to replace the ‘libsagsmp2.sl’ in ADI and WCP with the ADABAS 5 version. One I did this, all the errors went away. End of story. If this is an HP-UX configuration issue (to search the PATH for shared libraries or not) please let me know and I’ll pass it along to development. However, the fact that ADI and WCP as with other SAG products have their own shared libraries that are not placed in the LD\_LIBRARY\_PATH and SHLIB\_PATH I don’t see that I have a choice but to continue searching the PATH for shared libraries. Maybe the search order can be changed? Robert ---
**Author:** ![Robert\_E\_Bevis](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Robert\_E\_Bevis](https://techcommunity.softwareag.com/u/Robert_E_Bevis)\ **Post date:** [January 17, 2006, 9:18pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/14 "2006-01-17T21:18:11Z")
Hi Thorsten, You recommendation to change the ADABAS Wrapper is probably a good idea. I think this change needs to go to SAG development for the next PL of ADABAS. Maybe even as an Early Warning. But before I start making any changes… are you a really smart SAG customer or a SAG employee? 😉 Either way, now that I’m more or less past this issue, I definately have some other issues I would like to run past you. 🙂 Regards, Robert ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [April 2, 2021, 2:38pm UTC](https://techcommunity.softwareag.com/t/unsatisfied-code-symbol-smp-v213-in-load-module/57845/15 "2021-04-02T14:38:54Z")