There are a number of places that new users can use a lot of memory.  This is only a guess at what might apply in your shop. In a DATA step, new users have to realize that these steps are different: data new (keep=a list of final variables); set old; ** calculations; run; data new (keep=a list of final variables); set old (keep=just the variables I need to read in); ** calculations; run; The first step reads in all of the variables.  If you have a gazillion variables, that can consume memory. In PROC FREQ, the software tracks all combinations.  So this table would require enormous amounts of memory: proc freq data=purchases;    tables credit_card_no * date / noprint out=counts; run; In PROC MEANS (or PROC SUMMARY), the CLASS statement tracks all levels at once.  That can also consume memory: proc summary data=purchases;    class credit_card_no;    var amount;    output ... run; But there's no guarantee that the fault lies with the users.  And here at the discussion forum, we don't really have much of a clue as to what the users are actually doing.  These are just some pitfalls using commonplace tools. Good luck. ... View more

OK, these's much more to the COMPRESS function than I realized.  Sometimes I guess it pays to read the documentation before you post. http://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.htm#a000212246.htm "Keep" is illegal as a third parameter.  Use "K" instead.  But all of these macro variables may not be necessary.  Varying the third parameter may give you all that you need. Don't forget to read about the "o" as well, for speeding up the processing. ... View more

I'm afraid this is approach is in the "brute force" arena ... On the SAS side, you might set up a set of macro variables that contain allowable characters.  Just a couple of examples: %let caps_only = ABCDEFGHIJKLMNOPQRSTUVWXYZ; %let caps_plus_digits = ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789; That would let you apply the COMPRESS function down the road: var1 = compress(var1, "&caps_only", 'Keep'); var2 = compress(var2, "&caps_plus_digits", 'Keep'); It's clumsy, but at least it gives you a way to apply different rules to different fields.  And unfortunately, it will take some CPU time. ... View more

Here's a small test program I wrote to illustrate the issue with random numbers: data test; do i=1 to 1000;    if ranuni(111) < 0.5 or ranuni(111) >= 0.5 then output; end; run; You won't get 1000 records in the output data set, because the two ranuni functions generate different streams of numbers. ... View more

Hima, Not sure if it's a typo or you just need a set of fresh eyes to look at this ... The second AND should be OR. Also note, random number streams can be tricky.  I forget all the rules, but it is quite possible that the two ranuni(111) are generating different numbers.  If you want to make sure you are comparing to the same random number, generate it first: newvar = ranuni(111); Then refer to newvar in the IF statement. Finally, it looks like you have used < when you meant to use >. Good luck. ... View more

proc gplot data=whatever (obs=###) Pick a number that represents enough observations for 20 or 30 plots, and ignore the last plot since it may be incomplete. If you want a more scientific version, you could run through a DATA step to create a subset of your data: data subset;    set whatever;    by my_by_var;    if last.my_by_var then n_plots + 1;    output;    if n_plots=25 then stop; run; Then run PROC GPLOT on the subset. ... View more

My imagination must be on vacation today.  I appreciate the work you did to get this far, but I can't picture what the table would look like if you added a third variable.  I would need to see an example of the table structure that represents 3 variables. Did you try the LIST option I suggested?  It would give you the counts and the overall percentages (not row or column percentages). ... View more

Try this variation on PROC FREQ first, and see if it does what you need: tables pci*cabg*diagcath / MISSING LIST; If this isn't what you need, I would have trouble picturing what your report should look like.  You might have to give an example. ... View more

Just wondering ... why must you use PROC TABULATE to do this, when PROC FREQ already does it? At a minimum, if you use PROC TABULATE you will have to put each number in a separate cell. ... View more

Rick, you have it exactly right.  I just wanted to expound upon one of your points. Comparing CLASS STATE COUNTY; vs. BY STATE COUNTY; In the output data set using BY, there is one observation for each STATE/COUNTY combination. In the output data set using CLASS, you get those same observations, plus:  one observation holding a summary for the entire data set, one set of observations holding a summary for each STATE, and another set of observations holding a summary for each COUNTY.  The variable _TYPE_ in the output data sets tells you what the level of summarization is for that observation. The printed reports give you summaries at the most detailed level only, even if the output data sets would be different.  And, as Rick noted, the format of the reports would change. Finally, your colleague's recollection is correct.  Any observation where a CLASS variable is missing will be thrown out of the analysis.  The MISSING option changes that, treating missing values like any other value for a CLASS variable. ... View more