If you're accustomed to using "shell" commands from within your SAS programs (using the X command or SYSTASK statement, for example), you'll find that those statements won't work when you run your program from within SAS Enterprise Guide. When you try them, you will probably see one of the following error messages:
ERROR: Shell escape is not valid in this SAS session.
ERROR: Insufficient authorization to access SYSTASK COMMAND.
Out of the box, when SAS is configured for use by a client application like SAS Enterprise Guide, the shell command access is disabled through use of the -NOXCMD system option. Why? Well, in a distributed computing environment, your system administrators probably do not want SAS Enterprise Guide users to have full access to the shell environment on the host server.
If your SAS workspace is on a central server, you have just a couple of options:
- Use a custom task to run system commands on your local Windows machine, if that's what you need to do.
- Petition your system administrator to specify -ALLOWXCMD on the central workspace server. Good luck!
This same configuration applies even when using SAS Enterprise Guide with the SAS that's installed on your very own desktop. You might argue, "But it's my desktop machine! I should be able to run commands on my own machine." To which I would reply, "You're right!".
You can change the registered SAS command that SAS Enterprise Guide uses in order to remove the -NOXCMD startup option. But since this involves unseemly interaction with the Windows registry, you might prefer to use a tool that does this for you. I've placed such a tool here. (It's a ZIP file that contains a program and a ReadMe.txt file with instructions.)
This tool displays the currently registered SAS command and allows you to change it. In addition to allowing you to modify the SAS command startup options, you can use the tool to help synchronize the registered SAS command on a 64-bit Windows platform so that it can be used by a 32-bit process (such as SAS Enterprise Guide).
16 Comments
actually when you are running EG locally you need to change the registry to -xcmd and not allowxcmd. the later will not let you start the local server.
open registry and search for "sas workspace". here you find to registrations with noxcmd you have to change to xcmd instead.
Hi,
I'm trying to use the tool above to remove the -noxcmd option, but I can't seem to get it to work. I follow tyhe instructions - running the .exe file, selecting one of the identifiers, changing the -noxcmd (or changing it to -allowxcmd or -xcmd...I've tired them all!) and then clicking "Set it". When I do this, a window pops up asking me to confirm the action, I say yes, and then another window pops up that is blank. I click "ok" on this window (even though it says nothing), and check the identifiers - nothing has changed. Crud. Any suggestions??
Thanks.
Jenn
Because this touches the "local machine" section of the Windows registry, you must have appropriate privileges on your machine to make the change. You might try to right-click on the EXE and "Run as administrator".
I had the same problem, ran as administrator but was only able to change the 32 bit registry entries. I still am not able to run X commands on my SAS EG.
The registry key to examine is:
HKEY_CLASSES_ROOT\CLSID\{440196D4-90F0-11D0-9F41-00A024BB830C}\LocalServer32If you can run REGEDIT and view/change that to remove the -xcmd option, it should work. Note that in SAS 9.3, XCMD is allowed by default on local sessions.
Thanks. This worked well although I have never delved into registry keys before.
I look forward to getting an upgrade to 9.3 at some point.
Pingback: XCMD and SAS 9.3: working together again - The SAS Dummy
I used your little application and it worked perfectly. That's great!
Thanks.
Hi Chirs
My admin has set up x command for me. It is now working. I was able to execute basic commands (like mkdir, rm etc.) in the server. But I have a problem now.
I am trying to execute a shell script through X command (x "ksh test.scr &"). The shell command internally invokes a sas sysin using sas command. The issue is when I invoke the shell script, the sas sysin doesn't get triggered. Basically the sas command given inside the script is not getting executed.
test.scr contains : sas -sysin test.sas -log test.log
How do I overcome this issue?
Thanks !
Deepak, you might need to experiment with a different approach, such as %SYSEXEC or SYSTASK function. If you get stuck, SAS Technical Support should be able to help you to get it working.
Chris -
At our SAS 9.3 M2 grid installation we DON'T have the "Allow XCMD" checked for the SASApp workspace server.
I can run X commands from SAS EG 5.1, but can't run filename ref pipe ....
I get: "ERROR: Insufficient authorization to access PIPE."
Why can I run X commands but not pipe?
Will checking the "Allow XCMD" box for the SASApp workspace server make it possible to use pipe?
Hugh, there are a number of possible reasons that you see that message. For each code submission, you have two SAS environments in play: the SASApp workspace server, and a SAS grid node session. So it's important to understand where the code is running, as the options, user identity, and operating environment can affect how OS commands/shell access is processed.
It's possible that your FILENAME PIPE is referencing a resource that you (the account running the job) really does not have access to.
I suggest that you work with SAS tech support to determine the root cause for the error.
When I use X command to run batch job on unix server in SAS EG, the log file was not created. How to create the log file like when I run the job on unix terminal?
Thanks!
Hi Yihong, it was great to see you in person at SAS Global Forum. I'm not sure why the technique you're using isn't working, but I suggest working with SAS Tech Support to figure out which is the proper option to route the output where you need it. I assume you're using the LOG= option on the SAS command that you issue in the X statement?
It appears that there is something wrong with running the rm command from within an Enterprise Guide session. is there an option or configuration setting that could be preventing the removal functionality? Can someone help me.
The shell command runs using the account that you're connected with, so make sure that account can execute the rm command in the working directory. And...make sure the working directory is where you think it is. And...make sure the file you're trying to remove isn't in use. (For example, if you try to rm a data set that's loaded, or an XLSX file that has a libname assigned to it.)