X-FROM:  <MPERRY@ALBM1>
Newsgroups: bit.listserv.sas-l
Date:         Wed, 12 Aug 1992 09:58:07 EST
Reply-To:     MPERRY%ALBM1@ALBNYDH2.BITNET
From:         MPERRY%ALBM1@ALBNYDH2.BITNET
Subject:      PROC SYNCSORT under CMS summary.

Thanks to all who responded to my posting regarding the fact that PROC
SYNCSORT automatically reverts to the SAS SORT procedure using Syncsort
whenever PROC SYNCSORT encounters an input or output WORK file under
CMS.

The whole issue results from promotional literature mailed to our site
praising the benefits of the Syncsort written SYNCSORT procedure as
compared to using Syncsort via the SAS written SORT procedure.  The
Syncsort literature claimed 30-40 percent savings as compared to the SAS
SORT procedure using Syncsort.  Our systems section became very excited
about the prospect of BIG SAVINGS in sort time and I/O and made testing
PROC SYNCSORT a priority.  Syncsort even offers a method to cause SAS
to automatically try to use PROC SYNCSORT whenever PROC SORT is
called in a SAS program.  Thus, use of PROC SYNCSORT becomes transparent
to the user and there is no need to recode hundreds of PROC SORTs to
PROC SYNCSORT.  (Like an additional SORTPGM=BEST option.)

According to Syncsort, PROC SYNCSORT is unable to handle work files
under CMS because SAS may store part or all of the input or output
work file in memory with only the overflow portion being maintained in
the technically two level library named WORK.xxxxxxxx.  Thus, even
though most work files may be all or partially on disk under two-level
names like WORK.TEMP, PROC SYNSCORT defers to the SAS SORT procedure
to avoid the possibility of losing the memory portion of a file.
In addition, PROC SYNCSORT under CMS and SAS 6.07 defers to the SAS
SORT procedure whenever:

- A first-obs, NODUP or OBS= option is encountered.
- A where clause is used to subset the input file.
- The input or output data sets are compressed or on tape.
- The input file contains deleted observations.
- SAS/SHARE is used.

No one responding to my posting gave PROC SYNCSORT a rave review.
Most respondents also reviewed PROC SYNCSORT and decided the effort
require to purchase, install, test and maintain the product far
exceeded the potential savings of using PROC SYNCSORT.  A few
respondents suggested altering the WORKINIT option.  While we may
try a few more experiments, I think our site has seen and heard
enough to pass on these BIG SAVINGS.  I am also unclear as to how
much performance would be lost by not using the work library and
losing the benefits of SAS keeping a portion of the file in memory.

In sum, the savings are BIG and real within the constraints of the
conditions outlined above.  If your site sorts a great deal of
permanent SAS data sets within these constraints under CMS, PROC
SYNCSORT is for you and can be installed to work transparent to the
user.  Otherwise, appropriately file the Syncsort promotional
literature and save yourself some time.

*NYS*DoT*CMS*IBM*3090-400*SAS*5.18*6.07*GRAPH*FSP*STAT*ANYSUG*

      Michael F. Perry           Using SAS 5&6 under CMS for:
 Assoc. Computer Prog/Analyst      Bid analysis (BAMS/DSS) &
  NYS Dept of Transportation       Project Estimating
   State Campus, Bldg 4-220                Planning &
      Albany, NY  12232                    Management.

*NYS*DoT*(518)*457*5259*PLANES*TRAINS*AUTOMOBILES*BOATS*BIKES*