08-15-2017 12:56 AM
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.
08-15-2017 02:07 AM
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.
08-15-2017 04:25 AM
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?
08-15-2017 10:58 AM
@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.)
08-15-2017 11:25 AM
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.
08-23-2017 02:38 AM
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".
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.
@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).
08-23-2017 10:57 AM
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.