I have not had great success predicting which data sets will compress well.  I think I know how RLE should work, but there must be factors I'm not aware of.  So my practice with large data sets that I will create multiple times is to try all three settings on a data set, and just see which one works best.   It used to be said that compression could make programs run faster because I/O is slow, and the decrease in I/O with compressed data more than made up for the increase in CPU usage.  I don't know if that's still true with solid state disks, where I/O is much faster.   Our Unix disks have hardware compression, so using SAS compression might result in redundant compression at the physical level.  I don't know what overall effect that would have - faster?  slower?   Maybe compression doesn't matter as much as it used to.     The POINTOBS= data set option "Specifies whether SAS creates compressed data sets whose observations can be randomly accessed or sequentially accessed."  Also, "Specifying POINTOBS=YES does not affect the efficiency of retrieving information from a data set. It does increase CPU usage by approximately 10% when creating a compressed data set and when updating or adding information to it."   REUSE= is a related data set option: "Specifies whether new observations can be written to available space in compressed SAS data sets."  The documentation doesn't say what happens in uncompressed data sets.   My reading of this is that SAS keeps an internal table that maps observation number to physical location, and so the order in which observations are returned is not necessarily the same as the order in which they are stored.   I don't know if my reading is correct or not, but that would correspond with how values within an observation are stored - the varnum/logical order of a variable is not necessarily the same as its physical location. ... View more

I would probably use the prxmatch function, but the problem doesn't seem well defined to me.  What do you mean by "partial match"?  If "Hasan" matches "Hassan", why wouldn't "as" also match?  Or "sanitary"?   One of the spelling difference functions might be useful, but would probably be very expensive.   Maybe one of the Dataflux products would do this if you have it licensed.       ... View more

The code        age = intck('year', date2, date1);   will not always produce the result you might expect, because what it counts is the number of occurences of January 1 between the two dates:   69 data _null_; 70 years = intck('year', '31dec2019'd, '01jan2020'd); 71 put years=; 72 run; years=1 Use of the CONTINUOUS option might produce the result you want:   data _null_; years = intck('year', '31dec2019'd, '01jan2020'd, 'continuous'); put years=; run; The traditional method of calculating age in SAS, attributed to Billy Kreuter, is    age = floor(( intck( 'month', dob, death) - ( day(death) < day(dob)))/ 12); <https://www.lexjansen.com/pharmasug/2011/CC/PharmaSUG-2011-CC20.pdf>   There's a lazy method that just takes the difference in days and divides by 365.25.  Please don't use that method.   ... View more

PRXMATCH can test for a match against multiple strings. As was mentioned already, using the IN: construct would be easier (and probably faster) if the qualifying string is always at the beginning. ... View more

Since the time of Richard the Lionhearted, huh?  That's an interesting piece of trivia I would never have guessed.    I think it should be possible to create named ranges with the excelxp tagset using tagattrs to define the ranges, and with proc report it should be possible to define ranges smaller than entire rows or columns.  That's beyond my responsibilities and capabilities, but under Clarke's First Law it *is* possible.   It would be better to put that into the excel ODS destination.  I don't know anything about how non-tagset destinations are created.  Are they extensible in the way tagsets are, do you know?   ... View more

And even St. Nicolas himself was no sooner than the early common era. ... View more

You're absolutely right that using named ranges in Excel can greatly simplify Excel programming.  I don't think that many people are aware, for example, that you can use named range intersections to define cells, so in your first example I could refer to "(North_East Level)" instead of having to manually find "$B$2".  One table per sheet is also very helpful for auditable programs.   But if you want to do such programming against a workbook created by SAS, how would you do it?  I don't see a way in ODS EXCEL, ODS TAGSETS.EXCELXP, or PROC EXPORT to specify named ranges on output, and that could be very helpful.  Writing an Excel macro to name ranges in SAS, and then executig that macro once you're in Excel, seems like a kludge. ... View more

For a standard SAS library, the pathname does not include the filename.  You need (and can specify) only the directory name.   So omit the "SAMPLE1_DRUGS.SAS7BDAT" in the libname statement.   Personally, I don't think it's good practice to have special characters like ')' in a directory name, and I also don't think it's a good idea to store programs and and data under the sasuser.v94 directory.   If this code is running inside SAS University Edition, the pathname should be relative to the myfolders directory and use Unix naming conventions.  I can't tell whether you are running the code in SAS University Edition, or trying to get the data out of a SAS University Edition directory using a different version of SAS.       ... View more

Before writing a macro that generates code, you should have an example of working code similar to what the macro should generate.   Your macro is generating        set find(schools,"&zm1") >0    so SAS thinks that "find" is the name of a data set.  The parenthesis indicates that a data st option is to follow, but "schools" is not the name of a data set option.   What working code do you want to generate?   ... View more

There's a page on the old sascommunity.org page that describes four methods of doing look-ahead reads.     http://www.sascommunity.org/wiki/Four_methods_of_performing_a_look-ahead_read     ... View more

I wonder why the default string length in some cases is 200, not 256.   I remember that once SAS had an informal poll, which would we rather have, longer variable names or longer libref names.  The consensus was longer variable names, and that's what we got.   The length of libref names probably comes from MVS (now z/OS, something else before MVS), which has a maximum DDname length of 8.  The original member name length of 8 probably comes from the maximum length of MVS partitioned data set members (at one time, SAS data sets were stored as PDS members, not in a single big file).  I don't know where the length of 8 for variable names came from.  Maybe they went for uniformity, or though that no one would ever possibly need longer names than that.   ... View more

You got an answer.  You didn't like the answer.  Those are two different things.   You haven't explained why Git and shared libraries won't solve your problem.  With a commitment by your organization to encourage/require their use.   Also, if you are going to set up shared code and libraries it would be best to have a code review procedure in place as well.  ... View more