(See here and here for history)
I edited the shell script which is eventually called by run-saw.sh to start the sawserver, (OracleBI)/setup/sawserver.sh, to use trus:
Comment out the final line:
$SASAWSERVER
and insert as a new line:
tusc -fepan -o /tmp/sawserver_tusc.out $SASAWSERVER
The output of trus ended with this:
open("/app/oracle/product/10.2.0/lib/libstd_v2.so.1", O_RDONLY|0x800, 0) ……… ERR#2 ENOENT
open("/app/oracle/product/obiee/server/Bin64/libstd_v2.so.1", O_RDONLY|0x800, 0) . ERR#2 ENOENT
open("/app/oracle/product/obiee/web/bin64/libstd_v2.so.1", O_RDONLY|0x800, 0) …. ERR#2 ENOENT
open("/app/oracle/product/obiee/odbc/lib64/libstd_v2.so.1", O_RDONLY|0x800, 0) … ERR#2 ENOENT
open("/usr/lib/libstd_v2.so.1", O_RDONLY|0x800, 0) …………………………. ERR#2 ENOENT
open("/lib/libstd_v2.so.1", O_RDONLY|0x800, 0) …………………………….. ERR#2 ENOENT
open("/app/oracle/product/10.2.0/lib/libstd_v2.so.1", O_RDONLY|0x800, 0) ……… ERR#2 ENOENT
open("/opt/aCC/lib/hpux64/libstd_v2.so.1", O_RDONLY|0x800, 0) ……………….. ERR#2 ENOENT
which showed sawserver failing to find libstd_v2.so.1. The helpful chap on my SR at Oracle said this should be in /usr/lib/hpux64 (which it is) and so to add this to the SHLIB_PATH variable:
export SHLIB_PATH=/usr/lib/hpux64
If SHLIB_PATH already has a value then use the syntax ${SHLIB_PATH}:/usr/lib/hpux64 or use this anyway and set +u to stop the shell barfing on the unknown variable
Having updated SHLIB_PATH sawserver now starts up fine on this server now! w00t!
But – why did this just start happening now?? The same servers with the same obiee installation and same obiee configuration worked without the SHLIB_PATH being set last week, so why do they need it now?
