LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (January 2003, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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 of sorting.

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 seems OK.

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?

Thanks, Tim Berryhill


Back to: Top of message | Previous page | Main SAS-L page