Why does SAS BI use LD_LIBRARY_PATH, and can it be avoided?

[ICI_SAS_Admins]

I am going to preface this by saying that I am still trying to understand this whole issue, so please forgive me if my comments and questions below don't make any sense.

We recently upgraded to Sybase 16.  In the process, a new environment variable name LD_LIBRARY_PATH_64 was created on our SAS BI server.  I was previously unaware that SAS strongly warns against setting this variable (see 34579 - Errors occur when the LD_LIBRARY_PATH_64 environment variable is defined on Solaris systems ).  Now we are receiving errors with our SAS/Access to Oracle connection and our Java Virtual Machine calls.  Our Sybase DBA says that he has an easy fix.  The link SAS note above says they have two possible fixes.  I am not sure if any of the solutions will fix the issue without causing other issues.  So I started to do what a good SAS administrator should do and research the issue to understand what EXACTLY is not working.

During my research, I found multiple sites that basically say "do not use/modify LD_LIBRARY_PATH for your applications".  I even read places that describe commercial products (ex. SAS?) that use this variable described as "lazy programmers" and "bad programming"... two descriptions I generally do not associate with SAS.  They suggest that using a localized variable is a much better approach.  My understanding is that both LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 are lists of shared directories that are used by ld.  So why does SAS use these variables?  Why do they not create a SAS specific variable?

In addition to still trying to understand this better, I am now curious if it is possible to unravel SAS from the LD_LIBRARY_PATH variables.  Has anyone had to do this, or are there any good discussions on this topic?

Thank you for your help!

--Shaun

[jakarman]

"I even read places that describe commercial products (ex. SAS?) that use this variable described as "lazy programmers" and "bad programming"... two descriptions I generally do not associate with SAS."  SAS is nice at the fron-end going into the OS system internals the are not the nice. Enough troubles seen to classify SAS als lazy and bad programmers on that area.

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html  (tldp.org) And you find the LD_library_path as standard approach.  Although most systems these days are 64-bit programmed there is still a lot of 32-bit (and less) history.

Oracle documented the LD_Library_Paht_64 http://docs.oracle.com/cd/E19205-01/819-5262/aeude/index.html It is working as you described.

This is at OS level and guess what, most middleware tools liike all those database interfaces are middelware and following the OS conventions. Only a middleware tool like SAS is rather stubborn not following those guidelines. (getting the trouble). Is the SAS system an application, The SAS applications are the sas-programs build in your environment your business and are not the COTS ones by sas-institute.