08-24-2012 11:19 AM
We are having few Linux Script which we need to schedule it
We are using LSF scheduler for scheduling the Sas DI jobs
Before running Sas DI jobs we need to schedule the Linux shell script using LSF scheduler.
We have create the Sas DI job which will call the shell script by using the user written transformation and we thought of using X-command to invoke/execute the Unix shell script, but as per the company policy they have refused to give the access to x-command.
We need to use only LSF schduler for scheduling the Sas DI jobs and Linux Shell script.
Please let em know is there any other way we can invoke and schedule the Linux jobs using LSF scheduler.
Please guide me.
08-24-2012 10:25 PM
I believe the OEM LSF license you get with SAS only allows to schedule SAS jobs. LSF as such could be used to schedule anything but you would need to upgrade the license.
A "work around" and also to get SAS metadata job objects for scheduling within SMC is to have a little wrapper SAS code and then start anything else out of this wrapper code. That seems to be what you're trying to do.
I know that the standard installation setting for object spawner invoked SAS sessions is "noxcmd" so this doesn't allow the X command nor systask(). Are you sure that the same settings are also active for batch jobs (often they are not)? - Just run a "proc options" in batch.
Another thought: If you have SAS/Connect you could try to start the X command within a rsubmit block. Rsubmit allows you to pass your own cfg so I believe it should be possible to set option "xcmd" for such a child process. You have to try - I'm not 100% sure that there is not some SAS internal security check preventing you from doing this.
Your own autoexec file could simply look like:
%include <standard autoexec>;
This would give you your standard SAS environment with all the settings but then in the end set 'XCMD'. It shouldn't matter if NOXCMD is set in another config file as your XCMD at the very end will overwrite whatever has been defined earlier.
Let me know if this works for you.
09-03-2012 05:17 AM
I guess that one place to put the wrapper script is in the BatchServer, which I believe is the the location of the SAS startup script that is called from LSF. The object spawner is usually not involved in batch execution.
But in my world, if the company policy is not to allow XCMD, what you are looking for is a way to fool them. A work around would have the same impact (and security issues) as the XCMD approach. Wouldn't be more straight forward to open a discussion in this policy instead? What will happen if they discover your neat work around...?
08-25-2012 11:13 PM
I've tried to make this RSUBMIT idea work using SAS EG (which gets SAS sessions created via object spawner as DI Studio does) and on the way learned a few new and valuable things for myself like rsubmit and piping results.
When the parent session had XCMD set I was able to run the child process (rsubmit block) with NOXCMD (code below), BUT: when the parent session was running with NOXCMD setting XCMD for the child process had no effect. It didn't throw an error or warning - it just didnt' change the option value.
This behaviour kind of makes sense to me from a security perspective. I'm curious if someone else can find a way around this.
I still believe that for batch processing you should be able to run your code with XCMD as you can fully define what config files and autoexec's should be processed (passed as parameters to sas.exe). You just wouldn't be able to run your code out of DIS for unit testing.
As for your companie's policies: I would try to argue that even if such a policy might be appropriate for a production (and test) environment the same rules shouldn't be applied for a DI development environment.
signon p1 sascmd="sas -NOSPLASH -NOTERMINAL -ICON -COMAMID TCP -NOXCMD";
length x $100;
proc print noobs;
length x $100;
proc print noobs;