BookmarkSubscribeRSS Feed
🔒 This topic is locked. We are no longer accepting replies to this topic. Need further help? Please sign in and ask a new question.
ChrisHemedinger
Community Manager

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

SAS For Dummies 3rd Edition! Check out the new edition, covering SAS 9.4, SAS Viya, and all of the modern ways to use SAS!
4 REPLIES 4
jimbarbour
Meteorite | Level 14

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

 

 

ChrisHemedinger
Community Manager

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.

SAS For Dummies 3rd Edition! Check out the new edition, covering SAS 9.4, SAS Viya, and all of the modern ways to use SAS!
jimbarbour
Meteorite | Level 14

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

 

 

ChrisHemedinger
Community Manager

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 For Dummies 3rd Edition! Check out the new edition, covering SAS 9.4, SAS Viya, and all of the modern ways to use SAS!

hackathon24-white-horiz.png

2025 SAS Hackathon: There is still time!

Good news: We've extended SAS Hackathon registration until Sept. 12, so you still have time to be part of our biggest event yet – our five-year anniversary!

Register Now

Creating Custom Steps in SAS Studio

Check out this tutorial series to learn how to build your own steps in SAS Studio.

Find more tutorials on the SAS Users YouTube channel.

SAS Training: Just a Click Away

 Ready to level-up your skills? Choose your own adventure.

Browse our catalog!

Discussion stats
  • 4 replies
  • 8513 views
  • 4 likes
  • 2 in conversation