Because this comes up on the forum quite a bit, I'm posting this here as well.
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.
Read why, with workarounds, at:
Using the X and SYSTASK commands from SAS Enterprise Guide
If you try it, let me know how it works for you.
Chris
Hi, @ChrisHemedinger,
I think the link on this post is "dead". This might possibly be the correct link: https://blogs.sas.com/content/sasdummy/2009/11/19/using-the-x-and-systask-commands-from-sas-enterpri...
I'm one of those (ahem) lucky people for whom X and SYSTASK might be disabled. I say "might" because the weird thing for me is that SAS doesn't appear to even recognize X/SYSTASK as statements. When using the interactive debugger in SEG 7.15 HF2 (7.100.5.6112) (64-bit), I can't jump to a line with an X command or SYSTASK command, and if I execute the previous line and then press F10 again, it just jumps over the X/SYSTASK as though it weren't even there. Is this normal behavior? I was expecting an error message or warning. I'd like to ask our Admin to turn on SYSTASK, but I would like to know if SYSTASK is actually turned off or I'm experiencing some other problem before I submit a request.
Thank you,
Jim
Thanks for correcting the old link @jimbarbour. I've fixed the original post.
I think the behavior you're seeing WRT X/SYSTASK is because those are global statements (Valid in: Anywhere). That means that those statements are executed when the DATA step is compiled, not as part of a DATA steps normal iterations. You won't be able to set a breakpoint with the debugger.
So the true test is: did the command do what you expected it to? Usually if it's not permitted, you would see an error. PROC OPTIONS will show you ff NOXCMD is in effect.
Dear Chris:
Ah. That makes sense. I jumped to the wrong conclusion. 😞
I did notice that I couldn't put SYSTASK as plain text even into a macro because it would give me an error (which indicates that it is indeed executed at compile time). And, as you suggested, whether or not the tasks are occurring is the true test -- and I'm seeing the results of the task having executed, even when executed through the interactive debugger. I learned about the EG interactive debugger through, you guessed it, the SAS Dummy. (Best thing since sliced bread!!)
I've got it all working now.
I was submitting to UNIX, via a CALL SYSTEM command, a series of about 50,000 specific files to unzip from a .zip archive (yes, another idea from SAS Dummy). CALL SYSTEM executes serially and takes on the order of 40 minutes. Yipes.
So, my brilliant idea was to use a SYSTASK COMMAND with the NOWAIT option so as to run in parallel. I generate the individual SYSTASK commands in a data step as a $ variable and then CALL EXECUTE them. I then set up a WAITFOR _ALL_. Thereafter, I interrogate the individual &TASKRCxx macro variables (all 50,000+ of them) to validate that all the unzips were successful. Problem is that the TASKRCxx macro variables did not yet exist when the WAITFOR was resolved.
Solution? Another tidbit from SAS Dummy: DOSUBL. I do a quick macro invoked via DOSUBL which just says %GLOBAL &&TASKRC&SeqNo and is iterated from 1 to SeqNo (the number of files to be unzipped). The DOSUBL of course executes before the CALL EXECUTE's. Presto! Problem solved. All the variables are declared before they are interrogated.
The bottom line? Run time down from about 40 minutes to less than 15 -- and, yes, all thanks to SAS Dummy. I was going to name my first born son, SAS Dummy, but, for reasons unknown, my wife seems to be opposed to the idea.
So if anyone says you're spending too much time on SAS Dummy, you show them this post. I'm totally increasing both my scope and productivity because of SAS Dummy. Please keep making me look good.
With my thanks,
Jim
Aw shucks, I'm blushing @jimbarbour.
Because this is an old thread -- and because I like to close on a high note -- I'm going to lock this discussion. But please, feel free to open related new topics if you have more questions or ideas to share.
SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!
What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.