Run SAS script remotely (from same network)

[G81]

Hi,

I was wondering what the best way to run a sas script remotely is, without any additional non-standard plugins, and on a client machine that doesn't have SAS installed.

Is SAS/CONNECT required?

When I run a batch script, whether it's located on the server or the client, I run into problems with the sasv9.cfg file. I think this is because SAS isn't installed on the client machine.

I dont require data to be passed to the client, but a log file would be great.

I've looked at lots of different methods including batch process, sas/connect, powershell, sas integration technologies, etc, but all seem to require either a sas client installed or sas integration technologies.

[CTorres]

You can not run any SAS program in any server (machine) unless Base SAS is installed in that server.

Maybe you can map your disk in the SAS Server to batch submit your script and get the log in the same directory.

CTorres

[JuanS_OCS]

As far as I know, if you want to run SAS code on a machine (any machine) you will need SAS Base (sas.exe) as minimum requirement, since that is the interpreter of the SAS code.

[DBailey]

That's basically what the sas scheduler does in a server environment.  You could look at the actual code submitted from a scheduled job and mimic the statement to run your own code.

[jakarman]

Take that base requirement of having a SAS installation on a remote server.  (or WPS for similar sas base processing)

The question is running:

- running some sas code (program/source)

- getting a sas log (processing)

- having some results (output).

This is the classic way of sas processing once started with cards (that old paper ones 8- columns) producing those printed listings

It was update to be used on terminals (3270 sas 5.18) those 24*80 columns green of black 15" tubes.

Then is went to a DMS system as seen with SAS-pc and that is available on all systems using a terminal type. With unix that is a X11-server running on Windows.

Do you really want to work that way?   Just activate it, it is still SAS/foundation .         

[Tom]

Depends what you mean by run remotely.  If you can get a command line prompt on the remote machine then you can run the program on that machine.  If SAS is installed properly then normally it is a simple as typing the command sas followed by the name of the SAS program ("script").

[Kurt_Bremser]

You can direct SAS to read config/autoexec and write output/log from any accessible location (see the -config, -autoexec, -log, -print options).

So you need a network connection that makes a directory on your client visible to the server.

Alternate method: set up your autoexec and config in your home directory on the server, write log/output there, and use a file copy tool like WinSCP to transfer the results to your desktop. Or write output/log to the $HOME/public_html directory if you have a webserver installed on the SAS server that does USERDIRs.

[G81]

Thanks for help guys. I just want everything to run server side, but triggered from the client side. Tom & Kurt, that's the method I've been persevering with, but with no luck. I've tried the following from the client side. Same user with admin access to both client and server. Run in a command prompt with admin.

"unc-path-to-server\sas.exe" -sysin "unc-path-to-sas-script\test.sas"

This brings up a SAS message log on the client with the error cannot open sasv9.cfg SAS option -path not set

I've tried with the -CONFIG option

"unc-path-to-server\sas.exe" -sysin "unc-path-to-sas-script\test.sas" -CONFIG "unc-path-to-sas-nls-en\sasv9.cfg"

I dont get any error or sas message log pop up, but I know the script isn't running due to a sas perm data set not being created and a log not being created. Also have checked the task manager on the server.

Both the above work directly on the server. I've also tried with the -PATH option.

[Kurt_Bremser · Accepted solution]

With which tool (telnet, ssh) do you log on to the server?

If you try to run the server-installed SAS from your client command line, it won't start because it is not licensed there.

[G81]

That's it! I've now used psexec.exe \\servername sasdirectory\sas.exe -sysin sasscriptdirectory\test.sas

This runs on the server as expected. Thank you all for your help. Now I'm just putting some code on the client side server to work out when the sas script has completed and if successful.

The reason I'm doing all of this is to bring together processes from 3 different databases, and using a single tool to run things in the correct order and with error checking / email notifications etc.

[ronan]

I used PSExec in the past to launch remote SAS Scripts. The scripts were parsing metadata server logs and displaying active user sessions (SAS 9.1) back to the windows PC administrator.

This required afaik  the RDP SMB port 445 (3389 ?)  to be opened between your windows client and the remote server so this might be unsafe - & forbidden as well - in some controlled environment.

Moreoever the remote account was required to belong to the (local) Admin group.

I am not even sure PSexec trafic is encrypted - like a kind of telnet - so this might raise heated debate with your security enforcement officers if you ask him/her whether you're authorized

to send unencrypted admin password on the network ... :smileyconfused:

There was some unstability of the PSexec service component (Server Service) then . This was ages ago  - Win 2k03 - and ought to have beed fixed since then.

Another way - a little bit far-fetched - to submit remotely windows shell scripts lauching SAS programs is to create a scheduled job using Windows server scheduler.

This can be done without specifying any time/date schedule, allowing to run jobs interactively even from a remote windows session using SCHTASKS /RUN

http://ss64.com/nt/schtasks.html

Basically, afaik it also re-uses RDP SMB socket so this won't enhance your safety loophole, will it ?

There might now exist new tools with powershell wich might adress better those issues. Have a look.

Message was corrected by: Ronan Martorell Thanks @Jaap & @Juan for the articles.

[jakarman]

http://www.windowsecurity.com/articles-tutorials/misc_network_security/PsExec-Nasty-Things-It-Can-Do...

[Kurt_Bremser]

443 is actually the default https port, so I suspect that the traffic there will be encrypted.

OTOH, the whole discussion just shows how much better it is to use a real operating system for server operations.

Automating operations with ssh and ksh/bash scripting works like a charm.

[ronan]

My fault, sorry : RDP default port is (was ?) 445 or 3389 not 443 which is the TSL/SSL default port used on the internet.

To be fair, encryption did exist with RDP trafic even 10 years ago on Win2k03. But it required additional licences and setup ( cf. https://support.microsoft.com/kb/814590 ).

[JuanS_OCS]

Good updates on your entries. Thanks Ronan. To be honest, I was unaware about the encryption on RDP traffic from 10 years ago or more.

And about powershell, I am not sure if it address better this requirement. Now it is becoming very popular and trendy. In my personal opinion, in the end, all of those tools are doing mostly the same and they need same security requirements... the difference is the implementation of the solution and the security itself.