SAS Scheduler ID running X CMD

[njwmeme]

Hello,

I am currently trying to run a batch of SAS code through SAS scheduler(Flow Manager), which is using lsfadmin ID to execute. I will usually run with sasdemo ID(In SAS DI) which is OK, but when I run scheduler with lsfadmin, my job finishes without error but the code was not executed. 

My code basically goes to the hard disk directory to find for a particular SAS file and repeats until all directories are checked. Lastly it will compile all the SASfile.

x cd &path;
x dir > F:\SAS\test1.txt;
filename temp "F:\SAS\test1.txt";

Thank You.

Regards,

njwmeme

[Kurt_Bremser]

Run your external commands like that:

filename oscmd pipe "x cd &path;dir 2>&1";

data _null_;
infile oscmd;
input;
put _infile_;
run;

You will find all output (including error messages, that's what the 2>&1 is for) in the SAS log for diagnostic purposes. From that, you can take appropriate action. Once it delivers the expected result, you can replace this data _null_ step with your original step that read from the intermediate file, but use the piped command.

[njwmeme]

Hello Kurt,

After changing the codes, and run through flow manager, I got this error 'Insufficient authorization to access PIPE.'. May I know where to grant access to the ID to access PIPE?

[Kurt_Bremser]

---

@njwmeme wrote:

Hello Kurt,

After changing the codes, and run through flow manager, I got this error 'Insufficient authorization to access PIPE.'. May I know where to grant access to the ID to access PIPE?

---

Looks like you don't have XCMD enabled, which would also prevent the x statement from working.

[njwmeme]

Hello Kurt,

I have enabled XCMD from SMC side but still unable to run any XCMD with lsfadmin. May I know should I add 'options XCMD;' at the starting of my codes?

Thank You.

[Kurt_Bremser]

XCMD is enabled at SAS start, via configuration or commandline. After that, it can't be changed. So doing it in your codes won't work.

It seems (to me) you changed a server configuration that is not the one the lsf jobs are using, but then I'm no "SAS with LSF" expert.

[CHandberg · Accepted solution]

Hi...

If you want to enable XCMD for the batchserver, you have to change it in the sabatch.bat file

E.G \SAS\Config\Lev1\SASApp\BatchServer\sasbatch.bat

change it in theese lines:

if not {"%username%"}=={""} (
Set CMD_OPTIONS=-noxwait -xcmd -lrecl 32767 -config "%CONFIGDIR%\sasv9.cfg" -sasinitialfolder "%APPSERVER_ROOT%" %USERMODS_OPTIONS%
) else (
Set CMD_OPTIONS=-sasuser work -noxwait -xcmd -lrecl 32767 -config "%CONFIGDIR%\sasv9.cfg" -sasinitialfolder "%APPSERVER_ROOT%" %USERMODS_OPTIONS%
)

[Kurt_Bremser]

Actually, it is strongly recommended to make individual changes in the _usermods files:

sasbatch_usermods.bat (or sasbatch_usermods.sh on UNIX)

sasv9_usermods.cfg

autoexec_usermods.sas

as these will be preserved when SAS software is updated by the Deployment Manager. The non-_usermods files can and sometimes will be overwritten.

[CHandberg]

That is correct.

But in this case you have no choice.

The option -NOXCMD is set by default in sasbatch.bat, so you have no choice but change it here.

The same thing is that you have to edit and remove the REM from the last statements if you want to capture warnings.

So as you are saying; It is strongly recommended not to make individual changes to sasbatch.bat and should be avoided, but sometimes you have no choice but to do it.

[Kurt_Bremser]

You can do it with sasbatch_usermods.sh in UNIX:

#!/bin/ksh -p
#
# sasbatch_usermods.sh
#
# This script extends sasbatch.sh.  Add local environment variables
# to this file so they will be preserved.
#

set -A USERMODS_OPTIONS   # initialize empty list
# build up list by un-commenting (and adding) the lines you need (one line per t
oken)
# then replace the <argument> with the values you want for each token on the com
mand line
USERMODS_OPTIONS[${#USERMODS_OPTIONS[*]}]="-xcmd"
#USERMODS_OPTIONS[${#USERMODS_OPTIONS[*]}]="<argument>"
#USERMODS_OPTIONS[${#USERMODS_OPTIONS[*]}]="<argument>"
#USERMODS_OPTIONS[${#USERMODS_OPTIONS[*]}]="<argument>"
#USERMODS_OPTIONS[${#USERMODS_OPTIONS[*]}]="<argument>"

This change enables xcmd and let me run

filename oscmd pipe "ls $HOME";

data _null_;
infile oscmd;
input;
put _infile_;
run;

successfully. I guess that similar should be possible in the Windows SAS environment.

[CHandberg]

It works in windows as well!

What happens is that you get a command line with both -NOXCMD an -XCMD. Last one wins 🙂

(My OCD never allowed me to think this as a valid option 🙂 )

So you're right that it can be done by setting USERMODS_OPTIONS=-XCMD

I'm still not sure if I like it, because I would rather "reduce noise" in the commandline so there is no uncertainty about what is used (people tend to read from left to right 🙂 ) than avoid changing the file. The App-server folders will be saved and compared/updated anyway, when you update.

But that is just me. Your way of doing it is the correct one according to SAS standards.

Thanks for the correction!

/Christian

[CHandberg]

I was thinking XCMD is one thing...

Another thing;

Does the user LSFAdmin have the correct (Active Directory?) access to the folders?

[njwmeme]

Hello Christian,

I have granted LSFAdmin full permission to the folders. The thing is, scheduled jobs were supposed to be run by sasdemo, which has more permissions. However it was done by the previous developers to run scheduler via LSFAdmin, which is why I am trying to find a workaround to get the flow running smoothly.

[CHandberg]

Just to be sure: Does LSFAdmin have acces to the folder that contains the .sas-file (the deployment-directory) that is executed i the commandline from the scheduler?

When the scheduler executes and there is no RC and an empty or no log it is often because the ,sas.file either doesn't exists or the access is restricted.

[njwmeme]

Hello Christian,

Yeap I have granted LSFAdmin to full privilidge for the entire hard disk.
Anyways I have changed the sas batch file as you suggested and it works now.

Thanks alot 🙂