|Date: ||Sat, 11 Jan 2003 17:26:54 GMT|
|Reply-To: ||Tim Berryhill <tim@AARTWOLF.COM>|
|Sender: ||"SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>|
|From: ||Tim Berryhill <tim@AARTWOLF.COM>|
|Organization: ||Aartwolf Technology|
|Subject: ||DATASET ALREADY SORTED; COPIED INSTEAD|
Has anyone seen the rules for when PROC SORT will copy instead of sorting?
In my case, the input dataset was in fact already sorted but someone wanted
to use NODUP to remove duplicates. In the particular run I saw, the input
dataset had only one ob, so there could not be any duplicates to remove.
The SI knowledge base reports a bug under OS/390 which will convert a sort
to a copy even in the presence of NODUP, and the fact that the bug is only
reported for OS/390 hints that it is not a problem under unix, so it is
probably OK, but I considering buffing up the code for next month (monthly
production) and I would like to know when SAS saves CPU by copying instead
I made a few datasets and set the dataset option SORTEDBY=mykey, and if
there were more than one ob and NODUP or NODUPKEY, then SORT was not
converted to COPY. Only if there is only a single observation did I see SAS
8.2 on unix convert a SORT with NODUP or NODUPKEY into a COPY. Everything
I am just wondering, has anyone seen it in writing from SI that the
conversion of SORT to COPY for already sorted datasets is checking both for
the NODUP or NODUPKEY option and for more than one observation?