Cancelling a SAS job gone awry

5

Have you ever submitted a SAS program or query only to immediately regret it? It usually happens just as you finish clicking the mouse or lift your finger from the F8 key: you realize that your program has a horrible flaw that's going to make it run for hours or drag down a database server.

You immediately wish for access to Life's undo button. When you can't find one of those, you look for a way to cancel the job before it does too much damage. If you're running in SAS Enterprise Guide, you'll find it here:

  • Select View->Task Status.
  • Right-click on the offending task and select Stop.

You can stop the insanity...

If you're running SAS Enterprise Guide 4.2 and SAS 9.2, the task should stop almost immediately. If the task contained a query that delegated work to a database, stopping the job should also free up the database process. Then you're free to correct your program or task, and try again. No one else has to know about your little mistake.

(There was a lot of work done in SAS 9.2 to make that "cancel" operation work well and return control to you immediately. There is also much more power in the hands of the SAS administrator for monitoring SAS processes.)

If you're running SAS Enterprise Guide 4.1 with SAS 9.1.3, things might not go quite so smoothly. A task that contains a fairly intense SAS program might not give up control long enough to acknowledge the Stop directive. In SAS 9.1.3, the SAS session is pretty good about obeying the Stop request at the next "step" boundary, but that is of little comfort when the offending program contains just a single PROC SQL step with a crazy query.

In this case, you might need to take more drastic measures to stop a runaway job. You can right-click on the task in the Task Status window and select End SAS Process. That's the "kill switch" on your SAS session; it will cause the SAS job to end, but it will also end your SAS process and you'll lose whatever WORK data sets you might have accumulated up until that point. Also, it's sort of up to the database server to decide that there is no longer a SAS session driving it, and that it should stop working on your abandoned job. It might gracefully clean up, or it might not. Your system admin will probably let you know if it doesn't.

Tags SAS tips
Share

About Author

Chris Hemedinger

Senior Manager, SAS Online Communities

+Chris Hemedinger is the manager of SAS Online Communities. Since 1993, Chris has worked for SAS as an author, a software developer, an R&D manager and a consultant. Inexplicably, Chris is still coasting on the limited fame he earned as an author of SAS For Dummies.  He also hosts the SAS Tech Talk webcasts each year from SAS Global Forum, connecting viewers with smart people from SAS R&D and the impressive work that they do.

5 Comments

  1. Thanks for the info. I have EG 4.1 and I often get such problems. It seems fine with the "End SAS Process" function (but you often need to restart EG)

  2. Robert Meekings on

    Chris,

    Another option, on Windows, is to use something like the pstools from Microsoft SysInternals (http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx). As I understand it a similar approach is possible in Linux. I haven't tested this with EG, but we are using Base SAS 9.2 on PCs connecting to a Windows SAS server.

    You can find the process id from the name of the SAS work directory and then pskill this process from a DOS prompt:
    pskill [server]

    This also suffers from not knowing whether a database session is still active, but does not delete the work directory, although it will end the SAS session. This allows you to define a libname statement in a later session to access datasets in your orphaned work directory.

    Robert

  3. Robert,

    Thanks for the comment. The "Stop" approach (which just cancels the current job but keeps SAS running) is the kinder, gentler method for the end user to try.

    However, as an administrator you might need to occasionally kill runaway processes. pstools are great, and Process Explorer can be very helpful in deciding which of the many SAS processes need to be (shall we say) put down.

    See also:

    http://blogs.sas.com/sasdummy/index.php?/archives/5-They-all-look-the-same-to-me-SAS.EXEs-are-everywhere.html

  4. Any way to stop a job programmatically if it hasn't responded with any records after, say, a minute?

    • Chris Hemedinger
      Chris Hemedinger on

      You mean like a "wait until" and have that be a condition? No, not in this way. You might be able to do that with SAS Grid, which spawns/uses different SAS processes to do work. "Waiting for signal" is a thing that many computer languages have, but while SAS does have multithreaded PROCs, the SAS program flow doesn't support this.

Leave A Reply

Back to Top