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

Learn from the Experts! Check out the huge catalog of free sessions in the Ask the Expert webinar series.
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.

Learn from the Experts! Check out the huge catalog of free sessions in the Ask the Expert webinar series.
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.

Learn from the Experts! Check out the huge catalog of free sessions in the Ask the Expert webinar series.

SAS Innovate 2025: Save the Date

 SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!

Save the date!

SAS Enterprise Guide vs. SAS Studio

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.

SAS Training: Just a Click Away

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

Browse our catalog!

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