I think you are mostly running into trouble in the %put here; that's because you %unquote, which is inevitably going to cause an issue I think.  Unquoting attempts to resolve the macro variable, which is a problem here clearly.   I prefer %superq for these scenarios:   %if %sysfunc(find(%superq(paramname),%str( ))) > 0 %then %do; %let paramname1=%sysfunc(translate(%superq(paramname),%str(_),%str( ))); proc sql noprint; select value into :val&paramname1 trimmed from &ds where soundex(key) = soundex("&paramname"); quit; %put ========================<>==========================; %put ===> The Key is: &paramname and value is %superq(val&paramname1) <===; %goto exit; %end; No unquoting needed, I don't think.  I add TRIMMED option to PROC SQL so you don't get that big giant pile of excess spaces. ... View more

Moving it to work would resolve the problem assuming you have a new SAS session running each run(if this is running in batch, for example, as it sounds like it is). Each new SAS session has a different work directory, and each batch job starts a new SAS session. The main benefit of work is just this: it is the place to put temporary files where you know they will be cleared for you, so you don't have to worry about it. You don't need to perform that delete, SAS will do so when your SAS session closes.  Work also may be in a location that's more appropriate to frequent read/writes, depending on how your administrator set up your filesystem and your SAS environment (i.e., it could be on faster storage that's not backed up). As for why it's not deleting properly: especially with complicated or busy filesystems, sometimes things just get hung up. It doesn't happen to me often, but it's a more than once a month occurrence for sure. ... View more

I think what you're probably running into is that the delete process occasionally doesn't fully delete. Something in the OS/filesystem/whatever is losing track of it, and so the lock persists. One thing I'd recommend is if possible to use the work directory for something like this. If that's not possible (and I'd suggest it is _usually_ possible, even if you're sharing a dataset between processes), consider a dated dataset (where the name contains a date stamp). That way if something like this happens you don't have the risk of the process getting a lock. ... View more

It seems like it would be difficult to predict 5 or 10 year survival rates with any degree of precision with only 2 years of data, doesn't it? Some diseases have fairly stable 1-2 year survival curves with major drop-offs three or four years out, while some have fairly linear progressions. How does your model know if there's likely to be a spike in year 3 or 4? ... View more

Ha, I do remember enjoying Duke as well back in the day ... and I got my first SAS job from playing Civilization with my then future boss 🙂 Good times... -Joe ... View more

Oh, it's not even that; it's decades back really. Back when it was just mainframes, you'd just send code to them and get results. I'm talking 1960s to 1970s here. You didn't have IDEs, you just had a place to send whatever you wrote in a text editor somewhere to the mainframe to run. I don't think you can customize the right click button outside of certain parts (so for example you can customize it in explorer to do something different when doubleclick a dataset, but only because there's a specific place to do so). I don't see where you'd customize the editor version. ... View more

1 is easy to answer.  CLEAR ALL is there because a common use case for the older Program Editor, or similarly the ISPF editor, was to type commands in and then submit them - which cleared the screen, because they were being treated as commands, not as a program you wanted to save.  (That's why they had a "recall" option; that brings back the last command you submitted.)     So to give the Enhanced Editor that same functionality for those folks who still preferred the older style of doing things (Hi, Roger!), they have the "clear all" option on the right menu button. ... View more

If both first and last name are guaranteed not to have any spaces, you can just use SCAN.   If you specify 4 spaces because you want to treat single spaces as non-delimiters, then you have a few options.  The easiest is to use DLMSTR as '    ', I think.     data want; length first last $50; infile datalines dlmstr=' '; input first $ last $; ;;;; datalines; JOHN DOE MARY ELIZABETH SMITH JACKIE DOE SOPHIE DOE ;;;; run; But if you have other fields and want to read them as fixed width, you could read into NAME, then FIND '   ' and then use SUBSTR to parse it, or a perl regular expression. ... View more

I think you need to explain more of what you're doing. You're not going to be able to use the macro language in %SYSFUNC etc. to just write directly to random memory. Can you post a short, runnable example of a function that you'd like to turn into pure macro language, and why you want to do so? ... View more

The first thing I'd do is read Wendy's blog post here: https://blogs.sas.com/content/sgf/2013/08/14/four-ways-to-schedule-sas-tasks/ That covers the four common ways you'd use to schedule processes. Using EG on a server, you're probably going to prefer the third method I would guess, unless you have SAS Grid or similar in which case you may prefer the fourth. But the second method is also possible using EG, if you don't have a metadata server running for some reason and/or prefer to use windows tools. ... View more