A custom task to list and stop your SAS sessions

9

Last week I described how to use PROC IOMOPERATE to list the active SAS sessions that have been spawned in your SAS environment. I promised that I would share a custom task that simplifies the technique. Today I'm sharing that task with you.

How to get the SAS Spawned Processes task

You can download the task from this SAS communities topic, where I included it as an attachment. The instructions for installation are standard for any custom task; the details are included in the README file that is part of the task package.

You can also view and pull the source code for the task from my GitHub repository. I built it using Microsoft .NET and C#.

How to use the SAS Spawned Processes task

Once you have the task installed, you can access it from the Tools->Add-In menu in SAS Enterprise Guide. (By the way, the task should also work in the SAS Add-In for Microsoft Office -- though the installation instructions are a little different.)

The task works by using PROC IOMOPERATE to connect to the SAS Object Spawner. You'll need to provide the connection information (host and port) plus the user/password for an account that has the appropriate permissions (usually a SAS admin account). Note that the port value is that of the Object Spawner operator port (by default, 8581) and not the SAS Metadata Server.

spawnedprocesses
The task shows a list of active SAS processes. Of course, you're using a SAS process to even run the task, so your active process is shown with a yellow highlight. You can select any of the processes in the list and select End Process to stop it. You can drill into more detail for any selected process with the Show Details button. Here's an example of more process details:

processprops
Did you try the task? How did it work for you? Let me know here or in the SAS communities.

Custom task features within this example

If you're professionally interested in how to build custom tasks, this example shows several techniques that implement common requirements. Use the source code as a reference to review how these are built (and of course you can always refer to my custom tasks book for more guidance).

  • Submit a SAS program in the background with the SasSubmitter class. There are two examples of this in the task. The first example is an asynchronous submit to get the list of processes, where control returns to the UI and you have the option to cancel if it takes too long. With an asynch submit, there are some slightly tricky threading maneuvers you need to complete to show the results in the task. The second example uses a synchronous submit (SubmitSasProgramAndWait) to stop a selected SAS process.
  • Read a SAS data set. The SAS program that retrieves a list of processes places that result in a SAS data set. This task uses the SAS OLE DB provider to open the data set and read the fields in each row, so it can populate the list view within the task.
  • Detect errors and show the SAS log. If the SAS programs used by the task generate any errors (for example, if you supply the wrong credentials), the task uses a simple control (SAS.Tasks.Toolkit.Controls.SASLogViewDialog) to show the SAS log -- color-coded so the error is easy to spot.
  • Retrieve the value of a SAS macro variable by using SasServer.GetSasMacroValue("SYSJOBID"). This pulls the process ID for your active SAS session, so I can compare it to those retrieved by PROC IOMOPERATE. That's how I know which list item to highlight in yellow.
  • Save and restore settings between uses. Entering credentials is a drag, so the task uses a helper class (SAS.Tasks.Toolkit.Helpers.TaskUserSettings) to save your host/port/user information to a local file in your Windows profile. When you use the task again, the saved values are placed into the fields for you. I don't save the password -- I'm sure that I'd get complaints if I did that, even if I encoded it.
Share

About Author

Chris Hemedinger

Director, SAS User Engagement

+Chris Hemedinger is the Director of SAS User Engagement, which includes our SAS Communities and SAS User Groups. 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

9 Comments

  1. Pingback: Using PROC IOMOPERATE to list and stop your SAS sessions - The SAS Dummy

  2. I think I asked you about this functionality a while back. So many EG users are going to love this. Thank you!

  3. Miguel Alberruche on

    Hello Chris,
    Your article is fantastic!. Very good level (as usual). I have two questions;
    1) How to stop sessions from server and get sas end program executed.
    In our SAS Main > Logival Workspace Server, we've set propeties to execute a start and end SAS programs in order to get scaproc logs for all sessions (start=proc scaproc record, end=proc scaproc write).
    We want to stop all user SAS sessions at a certain hour to start Batch SAS process. Nowadays we are doing this from OS, but we are loosing scaproc logs.
    So we are wondering if it's possible to do this from within SAS Server in order to keep scaproc log's for those sessions.
    2) Performance details for SAS Sessions.
    I took a look at source code part that collect process details about SAS session, ie,
    proc iomoperate uri=&connection. launched='" || serverid || "'; list attrs cat='Information' out=pids" || y || "; quit;
    I'm wondering if it's possible to get performance details, using this code;
    proc iomoperate uri=&connection. launched='" || serverid || "'; list PERFORMANCE out=salida; quit;
    I tried but i'm getting this error:
    ERROR: Not connected to an IOM Server that supports the LIST PERFORMANCE command.
    Can you help me with this?. Thanks in advance !

    • Chris Hemedinger
      Chris Hemedinger on

      As far as the second question, it's possible that LIST PERFORMANCE doesn't apply to SAS Workspace sessions. I think that works with SAS Stored Process servers and perhaps other multiuser servers.

      The first question: I think the STOP command is basically executing an OS-level "kill" which won't allow the SAS sessions to clean up neatly. I don't know of a way to force an existing session to run a set of "clean up" code as you have built in to your process.

  4. Hi Chris, I am trying to use the Custom Task to list and stop the active SAS sessions. I downloaded the dll files from

    https://communities.sas.com/t5/Administration-and-Deployment/A-custom-task-to-list-and-stop-active-SAS-sessions/m-p/251340

    and then I created a folder named "Custom" in C:\Program Files\SAS\EnterpriseGuide\4.3 and pasted the dll file in this folder.

    But when I tried to run the Custom Task from SAS EG, it showed the error saying "Error: Procedure IOMOPERATE not found".

    I, also, tried to run the procedure using following code with my credentials

    %let connection=
    'iom://myserver.company.com:8581;bridge;user=sasadm@saspw,pass=Secret01';

    /* Get a list of processes */
    proc iomoperate uri=&connection.;
    list spawned out=spawned;
    quit;

    But getting the same error message. I am missing out something but don't know what.
    Can you please help me in this ? Thanks

    • Chris Hemedinger
      Chris Hemedinger on

      PROC IOMOPERATE was made available in SAS 9.3. I'm guessing that you have SAS 9.2?

      • Thanks Chris. Yes ... I will try on another platform where I am using 9.4. Thank you so much !!

  5. Pingback: Using PROC IOMOPERATE to list and stop your SAS sessions - The SAS Dummy

Back to Top