sapcheck environment variable

[former_member263733]

brconnect jobs in DB13 are failing. The job log gives me a pretty good indication why:

BR0252E Function fopen() failed for '/oracle/BBS/920_64/sapcheck/cdwcvtyd.sta' at location main-9

BR0253E errno 2: No such file or directory

From this, it appears that it is trying to access the log in the wrong directory (oracle/BBS/920_64) - not /oracle/BBS/sapcheck.

Documentation suggests setting the SAPCHECK environment variable to accomplish this. However, we have not tried this since we would like to understand how / why / where this errant setting setting got there. Also, we are assuming that if we do add this variable it needs to be added for the <SIDADM> user - is that accurate?

In addition, this is a "stage" system that should be configured identically to the DEV system which is working. We also have several other ancillary systems that are functioning as expected - which again, makes us hesitant to just add the "band-aid" solution of an environment variable.

[former_member263733]

Thanks to all of you who gave me suggestions

[madhukara_shenoy]

Hello,

brconnect looks the log file from the PATH $SAPDATA_HOME/sapcheck. make sure for OS user <SID>adm the SAPDATA_HOME is set correctly.

[former_member263733]

the environement variable for <SIDADM> is set correctly: SAPDATA_HOME=/oracle/BBS

That is what is curious here. All the other systems we have look like this and they are working. Again, that's kind of why we don't really want to just try and and a SAPCHECK variable to try and fix this - since we haven't had this problem in any of the other systems...

good suggestion though - keep'em coming...

[Former Member]

Jeff,

Another possibility is that brtools/brconnect is looking for this directory in /oracle/SID/920_64 , ie the ORACLE_HOME instead of the SAPDATA_HOME. In which case, you can create a softlink in /oracle/SID/920_64 called sapcheck to point to the /oracle/SID/sapcheck

The command (which you have to execure while in /oracle/SID/920_64 ) is

ln -s /oracle/SID/sapcheck sapcheck

Could you tell me if you have such softlinks in the systems where everything is working fine? Also check that your brtools versions are the same in all systems

I hope this helps

Andreas

[former_member263733]

there are no other such soft links, and the versions are the same.

It does look as though it is looking in ORACLE_HOME instead of SAPDATA_HOME

I will investigate the link fix you provided. However, we're more than a little curious how it got set that way - and how we might fix it at that root cause level.

Anyhow, thanks again for this suggestion - I really appreciate it!

[fidel_vales]

hi,

perhaps you can start BR* with a higher trace to check what environmetn variables are being taken.

What shell are you using?

If you are NOT using the SAP recommended one ( CSHELL ) then, change to it and try again,

If you are using KSHELL, be sure not only to define the variable, but to EXPORT the variable.

Another question(s)

Does it work if you start it at OS level?

Do you have an SAP instance on the DB Server or only the SAP gateway?

[Former Member]

Jeff,

To answer your question regarding which user's environment variables are used: When you run jobs from db13, the executables are being called from sidadm. However, depending on the permissions and ownership that the executable that is called has, the process can be run by orasid as well. So, if you call something from db13 , it starts with sidadm, but if the executable is owned by orasid and the s flag is set instead of x on the permissions, it will run with orasid. Maybe this is why the ORACLE_HOME is picked up instead of SAPDATA_HOME?

These are my permissions, which work fine in 5 installations we have here. Maybe you can run saproot.sh as root (this is under /sapmnt/SID/exe ) as root:

./saproot.sh SID

and the correct permissions will be set

-rwsrwxr-x 1 oraprd sapsys 4898192 Jan 21 2007 brarchive

-rwsrwxr-x 1 oraprd sapsys 5042888 Jan 21 2007 brbackup

-rwsrwxr-x 1 oraprd sapsys 6622328 Jan 21 2007 brconnect

-rwxr-xr-x 1 prdadm sapsys 5409416 Jan 21 2007 brrecover

-rwxr-xr-x 1 prdadm sapsys 2132496 Jan 21 2007 brrestore

-rwxr-xr-x 1 prdadm sapsys 6817944 Jan 21 2007 brspace

-rwsrwxr-x 1 oraprd sapsys 2758224 Jan 21 2007 brtools

Ensure that the brtools, brspace, brconnect etc executables in the system where you have the issue have exactly the same ownership /permissions with the system where everything works fine. Pay particular attention that the "set user id on execution" bits or flags are correctly set (the S instad of x ) (rwsr_xr_x)

I hope this helps

Andreas