The subject says it all...
Does anyone know why EG often (for my environment, more often than not) doesn't stop when you click Stop?
In my case, I had a simple data step, appending about 25 datasets together, for a total of ~ 3M records. Nothing remarkable there.
An upstream process creates an attrib statement (%include) for all the variables in the concatenated data.
There was an error in that generated code that showed up immediated in the log, so I clicked stop.
Since EG didn't stop immediately, I went to another task.
Two hours later, EG is still "stopping". Sigh...it would have been faster just to let the data step fail.
Task Manager --> Kill Task, here I come.
Good thing I am in the habit of clicking Save Project before submitting anything in EG. Been burned on that one before!
Any rumors whether this will ever be fixed in a future release of SAS and/or EG? Seriously, SAS, please fix this!
If there's a way to work around this issue, let me know.
I'm happy to open a TS track if it will make any difference, although I would think the EG R&D developers already know about this problem.
Hi @ScottBass,
Yes, we are definitely aware of EG's inability to stop certain running jobs. I'm sorry for the inconvenience it causes. I know it is a pain -- it really annoys me too!
Though it will not alleviate your pain, I can tell you the reason for this is on the server side. EG attempts to cancel the current job being run by the SAS server's language service, however the SAS server is busy (running the job) and for one reason or another (ex. perhaps waiting on DBMS response, disk IO, etc.) cannot be interrupted by the client. The client's cancel request falls on deaf ears, or at least cannot currently be executed by the server.
We are working on improvements in a future EG release to handle this scenario more gracefully on the client side. For example, we are considering giving users the ability to abandon an "unstoppable" and/or unresponsive workspace session (since we know there are periods the server cannot be interrupted), so they can at least easily spawn a new session without having to close or kill EG.
Casey
Register today and join us virtually on June 16!
sasglobalforum.com | #SASGF
View now: on-demand content for SAS users
Do you have any workarounds while the problem is being fixed ? What OS is your SAS server ?
Welcome to the wonderful world of client-server, @ScottBass !!
When you click Stop, what you're actually doing is sending a Stop request to the server rather than a Stop command. Unfortunately, the server will complete its current task before considering your Stop request.
I'd love to see it evolve to a "Stop NOW!" command, but unsure how that could be implemented in the current client-server architecture.
Curious - will this also be an issue in SAS/Studio?
Yes, SAS Studio will have the same issue, for the same reason.
Register today and join us virtually on June 16!
sasglobalforum.com | #SASGF
View now: on-demand content for SAS users
Hi @CaseySmith ,
Thank you for your response. Has there been any improvements on this issue in the past three years? I have had a couple instances in the past few months where I had to contact our data manager in order to stop an out of control SAS process because I couldn't stop it client side.
Sincerely,
Bill Spagnola
@whs278 - If it involves external databases then in my experience there has not been any significance change in EG behaviour.
Having said that EG8 in general is a major improvement compared with earlier versions.
If you could, make a call to OS Admin, let him invoke KILL command to kill sas session.
@Ksharp - Over-Kill. (How's that for a word play?!? ThankYouVeryMuchTryTheSteakWe'reHereTilSunday..)
It's a major wishlist item to be able to stop the current process without killing the actual SAS session (and losing all the interim work, etc.)
I have good luck with the Stop action when the running job is made up of many short-running steps (like a macro loop that processes 1000s of DATA steps). SAS yields its attention at the end of each step, so a Cancel request from EG is usually honored.
It's trickier when the job you're trying to stop is a really big expensive single PROC, like a modelling proc (PROC REG or similar) or SQL with a database query. SAS should yield and stop (similar to pressing Ctrl+Break in Base SAS windowing environment and selecting "Cancel submitted statements") -- but sometimes it doesn't work.
You can pull the hard line and select End SAS Process, which I find almost always works. That sends an OS-level Kill command to the SAS session via another route (not via the too-busy-to-yield LanguageService). All of your WORK data and session information is lost.
And finally, you could launch another EG session and try this method with a custom task, or the more manual method of PROC IOMOPERATE. These require admin-level credentials to connect to the SAS object spawner.
Chris
@Ksharp wrote:
If you could, make a call to OS Admin, let him invoke KILL command to kill sas session.
Luckily I have ALLOWXCMD on my server. But I don't have RDP access.
I've got this code which allows me to kill the runaway SAS session. If I've saved all my code in the EG project at least I won't lose my work, although I might lose hours of processing time (I have some really long running EG jobs).
Launch another EG project, then:
Get Tasks:
filename tmp pipe 'TASKLIST /v /fo csv /fi "username eq MyUserID"';
filename csv temp;
data _null_;
infile tmp;
file csv;
input;
put _infile_;
putlog _infile_;
run;
/*
proc import datafile=csv out=processes dbms=csv replace;
getnames=yes;
run;
*/
* customized PROC IMPORT data step ;
/**********************************************************************
* PRODUCT: SAS
* VERSION: 9.3
* CREATOR: External File Interface
* DATE: 27SEP16
* DESC: Generated SAS Datastep Code
* TEMPLATE SOURCE: (None Specified.)
***********************************************************************/
data WORK.PROCESSES ;
%let _EFIERR_ = 0; /* set the ERROR detection macro variable */
infile CSV delimiter = ',' MISSOVER DSD lrecl=32767 firstobs=2 ;
informat Image_Name $20. ;
informat PID 6. ;
informat Session_Name $20. ;
informat Session_Number $3. ;
informat Mem_Usage $10. ;
informat Status $10. ;
informat User_Name $32. ;
informat CPU_Time time8. ;
informat Window_Title $100. ;
format CPU_Time time8. ;
input
Image_Name $
PID
Session_Name $
Session_Number $
Mem_Usage $
Status $
User_Name $
CPU_Time
Window_Title $
;
if _ERROR_ then call symputx('_EFIERR_',1); /* set ERROR detection macro variable */
run;
* add the current SAS process to the list of processes to identify the current SAS session ;
data current;
if 0 then set processes;
image_name="sas.exe";
pid="&sysjobid";
session_name="YOUR SAS SESSION!";
output;
stop;
run;
proc append base=processes data=current;
run;
proc sort;
by image_name pid;
run;
* so it does not display in EG ;
proc delete data=current;
run;
Kill Tasks:
%macro code;
filename tmp pipe "TASKKILL /f /pid &word";
data _null_;
infile tmp;
input;
put _infile_;
run;
%mend;
%loop(
12345 <<< The appropriate process ID(s) from Get Tasks
);
Klunky, and so last century, but it usually frees locks on datasets, tables, etc., and allows me to restart the offending EG project, start from scratch, and get on with my day.
Hi All,
Thanks for the replies. Apologies for the delay in following up, I've been busy.
@CaseySmith: Thanks for the details on EG's stop processing. Yes, I suspected that the issue was the SAS server itself, not EG. I don't have access to DMS anymore, so I can't test whether stop processing is better there. But EG is what, 10-15 years old? (I'm too lazy to look up when it was first developed). However long it's been, in that time, has there been any progress in improving the interrupt processing in SAS? Discussions between EG and SAS Base R&D?
Your discussed future improvements, while nice, don't appear to address the root issue; rather, I'm merely able to pull the pin on EG easier without resorting to Task Manager. That's like stop processing, I guess. A bit analogous to "if your brakes fail, just steer your car toward that wall".
EG:
6.1M1 32-bit
Server:
OS Name: Microsoft Windows Server 2008 R2 Standard
OS Version: 6.1.7601 Service Pack 1 Build 7601
@AndrewHowell: I'm not sure client-server has anything to do with it. For example, I'm working a lot with SQL Server these days. Isn't SQL Server Management Studio a client, and the remote SQL Server Database Engine a server? When I submit a very long running, complicated query in SSMS, when I click stop, it stops. I've NEVER had a issue with SSMS stopping, or having to kill my SSMS client session. When I'm using SQL Server Data Tools (SQL Server's "DI Studio" ETL tool), when I click stop to stop a long running job, it stops. It's been a while since I've used Oracle's client, or TOAD, or Sybase's client, but if I recall correctly, when I clicked stop with all of these clients talking to remote servers...it stopped. So perhaps the issue isn't with the client-server model, but in SAS's implementation of a server.
@Ksharp: Again, that's one approach, but IMO it's "lipstick on a pig". https://en.wikipedia.org/wiki/Lipstick_on_a_pig.
@ChrisHemedinger: Thanks for those suggestions, I've saved them as notes and will keep them in mind for the future. However, I can't often convert my code to many short-running jobs, esp. with an RDBMS as the data source.
"SAS should yield and stop...but sometimes it doesn't work" - I would change that to "usually doesn't work" (at least in my environment) but yes I can see that the issue is with the SAS server rather than EG. In the olden days when we ran DMS, we just had the "client". My recollection is Cntl-Break worked better in DMS, but again I don't have DMS to test this. Then, when we moved to SAS 9 and EG in the client-server model, perhaps the server wasn't improved to cope with this issue?
I just now (5 mins ago) tried End SAS Process to stop another long running job that didn't respond to stop. After 5 mins I just used Task Manager. So End SAS Process didn't work for me. I have learned to always click Save before selecting stop.
Re: the custom task or PROC IOMOPERATE...thanks for the workarounds, perhaps this can be incorporated into EG out-of-the-box rather than requiring a custom task?
Lastly, when I compare EG with other client tools such as SSMS and SSDT/SSIS - and I really want to like EG more, I'm a "SAS guy" - but being completely, totally unbiased and objective...the user experience with those clients is simply better.
(At least with respect to stop processing - EG is MUCH better with point and click code generation, although it too could take some hints from SSMS functionality such as its RMB script generation capabilities).
Hi, Scott
Yes, you've definitely poked one of the sore spots in Enterprise Guide. Much of what you say is correct, but I differ with a couple of your opinions:
As an Enterprise Guide user since Version 2, I give you my solemn assurance that the STOP functionality works INFINITELY better than it did back then!
With regards to SQL Server tools, it's not surprising that they work better on jobs connecting to SQL Server...they're written by the same company! How well do SSMS and SSDT work against Oracle data sources, or Greenplum, or Hadoop, or SAS datasets? You're comparing apples to oranges on this one, I'm afraid. I don't know of any products that interoperate with as many data sources as SAS.
Tom
@TomKari wrote:
Hi, Scott
Yes, you've definitely poked one of the sore spots in Enterprise Guide. Much of what you say is correct, but I differ with a couple of your opinions:
As an Enterprise Guide user since Version 2, I give you my solemn assurance that the STOP functionality works INFINITELY better than it did back then!
With regards to SQL Server tools, it's not surprising that they work better on jobs connecting to SQL Server...they're written by the same company! How well do SSMS and SSDT work against Oracle data sources, or Greenplum, or Hadoop, or SAS datasets? You're comparing apples to oranges on this one, I'm afraid. I don't know of any products that interoperate with as many data sources as SAS.
Tom
Hi Tom,
I disagree with your analogy.
I compared SSMS - SQL Server, both written by Microsoft. Stop processing works.
EG - SAS Server, both written by SAS Institute. Stop processing doesn't work.
SAS's ability to work with other heterogeneous data sources is a separate discussion, not relevant to this subject.
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 16. Read more here about why you should contribute and what is in it for you!
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.
Select SAS Training centers are offering in-person courses. View upcoming courses for: