ERROR: Insufficient authorization to access /sas/SASConf/Lev1/SASApp/

[Mahis]

Hello everyone,

I was trying to schedule a job in SAS Management Console using Schedule Manager. When I tested a simple program with the following code:

proc setinit;
run;

the program ran successfully.

But, when I tried to schedule another program that generates a .lst file during its execution, instead of generating the .lst file in the same directory as the SAS script, it attempted to write it to /sas/SASConf/Lev1/SASApp/.

This led to the following error:

ERROR: Insufficient authorization to access /sas/SASConf/Lev1/SASApp/get_data.lst.

To avoid this error, I would like to know how I can specify another path for get_data.lst.

Here is the full command in the job:

/sas/SASConf/Lev1/SASApp/BatchServer/sasbatch.sh -log /saslogs/recup_available_#Y.#m.#d_#H.#M.#s.log -batch -noterminal -logparm "rollover=session" -sysin /sas/SASConf/Lev1/SASApp/SASEnvironment/SASCode/Jobs/get_data.sas

[Tom]

I have no idea how that sasbatch.sh script works as I just use sas script to run SAS and that script DOES NOT change the working directory before starting SAS.

If you have no control over the working directory that is set when your SAS code starts you can either 

1) Use a fully qualified name when referencing a file.

infile '/some directory name/getdata.lst' ;

2) Change the current working directory at the start of your SAS program so that it is a directory that has the files you want to read or allows you to write the file you want to write.

%let sysrc=%sysfunc(dlgcdir(/some directory name/));

[SASKiwi]

One option is to add an ODS LISTING statement at the beginning of your program to direct output to a different directory:

ods listing file = '/folder1/folder2/output.lst';

Another way is the -PRINT option on sasbatch: -print ' folder1/folder2/output.lst'

[Tom]

If that batch file works like the normal SAS command then you can add -log and -print options to tell where to write the .log and .lst files that SAS creates.

[yabwon]

I smashed my head a few times with this. Running the following code at the start of the session (e.g., in autoexec) helped:

/* set "current path" to WORK */
%put %sysfunc(DLGCDIR(%sysfunc(pathname(WORK)))); /* DLGCDIR changes current directory */
filename _ ".";
filename _ list;
filename _ clear;

Bart

[Tom]

---

@yabwon wrote:

I smashed my head a few times with this. Running the following code at the start of the session (e.g., in autoexec) helped:

/* set "current path" to WORK */
%put %sysfunc(DLGCDIR(%sysfunc(pathname(WORK)))); /* DLGCDIR changes current directory */
filename _ ".";
filename _ list;
filename _ clear;

Bart

---

I don't understand why they don't just fix the sasbatch script to set the current directory before it launches SAS?  I cannot think of ANY reason why launching with the goofy path that should be readonly to all users makes any sense at all.

You wouldn't tolerate such behaviour from other unix commands like.  Image if you ran sed on a file and it wrote the results to some far away directory you didn't specify?

That is how our local sas script on Unix works to submit SAS jobs to LSF grid.  It makes sure to on the GRID node where SAS is running that it moves to the current directory before calling SAS to run the program.

If the current directory is not mounted on the node where SAS will execute then you get set to your HOME directory instead.  My impression that this is a basic feature of LSF grid manager and not anything fancy.

[yabwon]

@Tom , I don't know "why they don't just fix the sasbatch script".

If I were a SAS developer I would surely insist on change(*), but I'm not.

If I were a SAS server admin I would set that up in the server configuration, but I'm not too.

I'n a user and just proposed a potential solution to a other user's problem. 

🙂

Bart

(*) Maybe the have so other dependencies and that's why it starts in that dir.

[Patrick · Accepted solution]

@Mahis If you want to write a report to an output destination when running in batch then the program should define the output destination as part of an ODS statement. 

SAS executable parameter -print <path> allows to define the default path for list output. If not set then the directory from which SAS starts will get used.

SAS installation default doesn't set -print and the directory from which SAS starts when using  .../SASApp/BatchServer/sasbatch.sh is .../SASApp

As a SAS Admin you could decide to set the -print default to a directory of your choosing - and you've got various options to do so. In the following two of them.

You could add an explicit -print parameter to the command line for the data step batch server in SAS Metadata. 

In the example it's /dev/null because almost always such .lst output under .../SASApp just gets created "by mistake" and is nothing developers/users are even aware of unless they get a permission error.

You could of course also set the path to some directory where no one has write access (even admins/functional users) so everybody gets an error if trying to run code that creates such .lst files.

Another option is to set the default print destination in .../SASApp/BatchServer/sasbatch_usermods.sh

....and then there is of course also the option @yabwon already proposed which you could apply in .../SASApp/BatchServer/autoexec_usermods.sas

The autoexecs and batch.sh files are cascading so if you want to set such a default on a wider system level then just set it there (i.e. under .../SASApp).

[Mahis]

Thank you all for your help. Changing the current working directory and adding the option of ODS listing solved the problem. But I started encountering other errors that I normally don't get when I run the program manually. After adding the -print /output path in the command line in SAS Management Console, the problem has been resolved. Thank you so much.