As a side note to Tom's very thorough explanation (thanks!), many people think the NOTE in the log about automatic type conversion should be treated as an error, to avoid problems like this.  Many log scanners are coded to treat this NOTE as not allowed to appear in a log.   There is an undocumented system option which will allow you to turn this problematic NOTE (and others) into an actual error:   1 options dsoptions=note2err ; 2 data _null_; 3 end_date= '04OCT2014'd; 4 Date1=SUBSTR(End_Date,1,8)*1; ERROR: Numeric value found where character value needed at line 4 column 16. ERROR: Character value found where numeric value needed at line 4 column 9. 5 put (_all_) (=/); 6 run; NOTE: The SAS System stopped processing this step because of errors.       ... View more

You mention upload and download.  Can you describe your environment a bit more?     Is this SAS running on a server, or local PC SAS?  If you've got a SAS dataset sitting on a Windows server, and then you're exporting and downloading a CSV, it could be the the network speed is causing the long run time.  As a test, you could change your code to write the CSV file to the Work library.  That should show how long it takes to write the CSV file, without the overhead of network transfer.  Then perhaps if you determine the issue is network latency, you could work with your admin on that, and perhaps consider compressing the CSV file before it is transferred.   Typically I've found PROC EXPORT to generate a CSV to be fast, so I would give that a try to see if it can handle your data. ... View more

As you say, you can use PROC FORMAT to map one value to another.   Once I had a problem where I needed to map three values into another value.  I started to build a new variable that would have the three values concatenated, and was going to build a format to map the concatenated value to my target value.   Then I remembered that SAS has hash tables.  You can define a hash table that has 3 key values, and use that as a lookup.   As to whether a hash table is "best" or "more efficient", it really depends on your use case.  There are lots of ways to do a lookup in SAS.   ... View more

You've got some good recommendations already.     You could also add a PUT statement to show the values of ICD10Code and Mic.  If the PUT statement does not execute, that means you don't actually have the value T21.06XA in your data (maybe there are leading spaces, or capitalization issues, or... )   data want ; set have ; IF substr(ICD10Code,1,3)="T21" & substr(ICD10Code,8,1) in ("A", "B", "C") THEN MIC=1; IF ICD10Code="T21.06XA" then put ICD10Code= Mic= ; run ; And of course it always helps to look at your data:  proc freq data=have ; tables ICD10Code*Mic/missing list ; format _all_ ; run ; The IF statement you posted works, so it's likely that the value of ICD10Code is not matching your expectation.   1 data have ; 2 ICD10Code="T21.06XA" ; 3 run ; NOTE: The data set WORK.HAVE has 1 observations and 1 variables. 4 5 data want ; 6 set have ; 7 IF substr(ICD10Code,1,3)="T21" & substr(ICD10Code,8,1) in ("A", "B", "C") THEN MIC=1; 8 IF ICD10Code="T21.06XA" then put ICD10Code= Mic= ; 9 run ; ICD10Code=T21.06XA MIC=1 NOTE: There were 1 observations read from the data set WORK.HAVE. NOTE: The data set WORK.WANT has 1 observations and 2 variables. ... View more

Thanks @Ksharp .     I didn't think your code would work because calculatedDate stores a single quoted string with calls to %sysfunc: 1 %let mm=09; 2 %let yyyy=2025; 3 %let calculatedDate ='%sysfunc(INTNX(MONTH, %sysfunc(MDY(&mm., 1, &yyyy.)),0,e),yymmdd10.)'; 4 %put &=calculatedDate; CALCULATEDDATE='%sysfunc(INTNX(MONTH, %sysfunc(MDY(&mm., 1, &yyyy.)),0,e),yymmdd10.)' I guess I forgot (or never knew?) that %bquote will resolve macro triggers inside a single quoted string. 5 %put %bquote(&calculatedDate); '2025-09-30'     ... View more

Looks like you've got a solution.  I suggest you mark your answer as correct / accepted.   I'm surprised that memtype=data would slow things down that much, but then I've never used that option on PROC CONTENTS.  Looks like it tells SAS to pull some metadata from every dataset that exists in the library. ... View more

I'm also having a hard time understanding your question.  The first two sentences are clear, but I can't understand "I suspect there may be combinations of the outcome positive observations which may be significant for certain variables"     In addition to more description to the problem, example data might help.  Perhaps an example dataset with say four variables (your one outcome/dependent variable and three variables that are predictors / independent variables).  Example data should help you  explain what you mean by "significant for certain variables" and "which observations might be similar to each other based on the variables." ... View more

If you don't get a helpful response here, I recommend you contact SAS tech support.   Note the earlier "Mapping error" in the IOM logic note.  I don't know what that is about, but typically with SAS the recommendation is to review the log and focus on the earliest error first. ... View more

Can you post the log from running the autoexec?  Is that the only error message you see in the log? ... View more

This snowflake time travel feature looks cool.  Agree with others, you'll likely need to use explicit pass through so that you can submit native snowflake SQL from a SAS job.  When you use implicit pass through, SAS translates that SAS SQL into Snowflake SQL for you.  But there are plenty of features in Snowflake which do not have SAS equivalents.  To access those, you need to write in Snowflake, not SAS. ... View more

My understanding (after reading the paper and Tom's explanation) is that PROC COMPARE calculates Diff  for each record as the difference between the two values, and DiffPct is that difference divided by the value in the Base dataset.   So it's the Diff and % DIff you see in the usual Value Comparison Results.    Then the summary stats are summaries of those variables , Diff and DiffPct.   Below uses the PROC COMPARE example I posted, and uses a DATA step to calculated Diff and DiffPCT and PROC MEANS to calculate the summary statistics.  This is the simple case, where all rows match.     data class ; set sashelp.class ; if name='Alfred' then height=70 ; run ; proc compare base=sashelp.class compare=class allstats ; run ; data want ; merge sashelp.class (keep=Name Height rename=(Height=Height_base)) class (keep=Name Height rename=(Height=Height_comp)) ; by name ; diff=Height_comp-Height_base ; diffpct=diff/Height_base ; run ; proc means data=want n mean std max min stderr t probt; var diff diffpct ; run ; I'm a big fan of PROC COMPARE, but have never used these stats.  I can see how N, MIN and MAX could be useful summary information.  Especially in the case of a big dataset that has lots of small differences due to numeric precision or whatever. ... View more

So you've got SAS 9 running on your local PC, and you're using RSUBMIT to submit chunks of code to different cores on your local PC?  So there's no network or remote server involved at all? Can you post a little example where you run PROC CONTENTS in your main session and then run it again in a child session and see the difference in execution times?   I haven't used RSUBMIT to spawn local sessions before.  Is the code something like:   options autosignon sascmd="C:\Program Files\SASHome\SASFoundation\9.4\sas.exe" ; rsubmit foo wait=no; options fullstimer ; data foo ; array x{300} ; run ; proc contents data=foo ; run ; endrsubmit ; signoff ; ?   When I run that, the PROC CONTENTS step completes in .04 seconds:   1 options autosignon sascmd="C:\Program Files\SASHome\SASFoundation\9.4\sas.exe" ; 2 rsubmit foo wait=no; NOTE: Remote signon to FOO commencing (SAS Release 9.04.01M7P080520). NOTE: Remote signon to FOO complete. NOTE: Background remote submit to FOO in progress. 3 signoff ; NOTE: Remote submit to FOO commencing. 1 options fullstimer ; 2 data foo ; 3 array x{300} ; 4 run ; NOTE: The data set WORK.FOO has 1 observations and 300 variables. NOTE: DATA statement used (Total process time): real time 0.01 seconds user cpu time 0.00 seconds system cpu time 0.00 seconds memory 1804.71k OS Memory 8660.00k Timestamp 11/10/2025 05:06:49 PM Step Count 1 Switch Count 0 5 proc contents data=foo ; 6 run ; NOTE: Non-portable document will be produced. The current settings of FORMCHAR use nonstandard line-drawing characters and the resulting output file will not render correctly unless all readers of the document have the SAS Monospace font installed. To make your document portable, issue the following command: OPTIONS FORMCHAR="|----|+|---+=|-/\<>*"; NOTE: PROCEDURE CONTENTS used (Total process time): real time 0.04 seconds user cpu time 0.00 seconds system cpu time 0.00 seconds memory 3294.53k OS Memory 10964.00k Timestamp 11/10/2025 05:06:49 PM Step Count 2 Switch Count 1 NOTE: The PROCEDURE CONTENTS printed pages 1-6. NOTE: Remote submit to FOO complete. NOTE: Remote signoff from FOO commencing. NOTE: SAS Institute Inc., SAS Campus Drive, Cary, NC USA 27513-2414 NOTE: The SAS System used: real time 0.94 seconds user cpu time 0.01 seconds system cpu time 0.01 seconds memory 10381.56k OS Memory 10964.00k Timestamp 11/10/2025 05:06:49 PM Step Count 2 Switch Count 45 NOTE: Remote signoff from FOO complete.   I'm still struggling to imagine how PROC CONTENTS could take a full second to execute, since all it does is read dataset metadata.  Is it just PROC CONTENTS that runs surprisingly slow, or do other PROCS  run slow?  How about DATA steps?   I wouldn't switch to dictionary tables.  In my experience PROC CONTENTS is usually faster than dictionary tables. ... View more

@k_k_ wrote: Maybe I am wrong and I had a false understanding on "having...". I have understood it so far like a "where"-condition that throws away the other data.  I will try and find out if this works tomorrow, haven't got access to the data right now. I'm not really a big SQL guy... the HAVING clause is similar to WHERE clause, but HAVING filters data after it has been aggregated by the group by.  So the counts are still based on all the data.  See the docs: https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/sqlproc/p1n8ntmltj8ct6n1hso7x2ys6sbw.htm   The code I posted returns your desired WANT dataset:   Obs Color House Type Day Name Count 1 2 3 garage 71 minni 2 2 2 7 bungalow 16 bad 2 3 2 8 bungalow 3 cold 1 4 5 2 garage 7 10 1 5 5 80 bungalow 8 15 1 6 5 80 garage 9 8 1 ... View more