HDTenEightyP/NetNews huggingface dataset:
Return-Path: <derek@wubios>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.sas-l
Date:         Wed, 16 Dec 1992 09:17:30 CST
Reply-To:     Derek Morgan <derek@WUBIOS.WUSTL.EDU>
From:         Derek Morgan <derek@WUBIOS.WUSTL.EDU>
Subject:      Re: PROC SORT NODUPLICATES is no good
Comments: To: Andy Norton <76350.1604@compuserve.com>
Comments: cc: SAS Mailing List <SAS-L@ohstvma.ircc.ohio-state.edu>
              Norton" at Dec 15, 92 6:12 pm

  Andy Norton replies:
>
> I'm sorry but I truly don't understand your point.  NODUPLICATES can
> only remove duplicates that occur adjacent to each other.  One way to
> make these duplicates adjacent is to sort by _ALL_ (tell me again why
> this might not work?).

  If the variables in the data set aren't ordered in a logical sort fashion:
  (Using the above example)  D1 D2 D3 D4...D37 C1...C38 ID LOCATION EVNTDATE;
  where you want it sorted by LOCATION, ID, and EVNTDATE while removing
  duplicates would cause you to write a sort statement like this:

  PROC SORT NODUPKEY;
  BY LOCATION ID EVNTDATE D1--C38;  /* BY _ALL_ would be equivalent to: */
                                    /* BY D1--EVNTDATE and you'd have   */
                                    /* to sort again.                   */

>I suppose that some data source could generate
> duplicates in such a way that they were always adjacent, so there is
> no need to sort.  Is this what you are dealing with?
>

 Yes. In fact, I frequently need to obtain values from a previous data point
 on a given subject, so during the merge process, the data wind up being
 adjacent. I understand the point about non-adjacent observations. My FM says
 that NODUPKEY only works on adjacent observations also. (_SAS Procedures
 Guide_, 3rd Ed., pp. 510.)

 Derek Morgan
 Washington University
 Division of Biostatistics
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Original_To:  BITNET%"SAS-L@UGA.BITNET"
Original_cc:  MMCDERMO
Newsgroups: bit.listserv.sas-l
Date:         Fri, 18 Dec 1992 09:14:00 EST
Reply-To:     Mike McDermott phone 993-3126 <MMCDERMO@GMUVAX.BITNET>
From:         Mike McDermott phone 993-3126 <MMCDERMO@GMUVAX.BITNET>
Subject:      Viewing text files in SAS

E. Bell wants to let his user view output which has been written to a file,
preferably while remaining in a SAS session.  Although I am running SAS 6.06
on a VAX (VMS 5.5-1) and he is running PC-SAS, I think that the features I
will describe are probably available in both environments.

1.  Although "include" does not work on the Output screen of Display Manager,
it works just fine for this purpose on the Program Editor screen.  Of course,
I have to put the file name in quotes so that SAS does not append ".sas" to
the name I write before looking for the file; but I brought in a 132-character
wide file and browsed around it very nicely.  When I had finished, I just wrote
"clear" and the program editor was free to edit programs as usual.

2.  For myself, I usually let my output go first to the Output screen of
Display Manager.  If I like it, I use the "file" command to send it to a
file from which I can download it to my PC for printing from WordPerfect, or
I go to the Output Manager screen to send parts of the day's output to files.
I don't use the Print feature of Output Manager myself, but that is because I
prefer to print locally rather than on the VAX system printer ... concerns of
mine which needn't worry anyone else.  I should think that PC-SAS would give
excellent Print results from the Output Manager screen *provided* that the
output had been formatted for a print page rather than for screen display.

When I first began to use Display Manager, I didn't realize that the output on
the Output screen didn't *have* to be a 78-character by 20-line page, with
page numbers cumulating through a session.  I now routinely include in each of
my proc steps which will generate output an "option ls=75 ps=64 pageno=1;" and
the results are just what I want for my preferred letter-size report format.
Just put your own numbers in and you have screen viewing *before* file keeping
and/or print making.

Mike McDermott, George Mason University, Fairfax, VA
MMCDERMO@GMUVAX.BITNET           Voice: 703-993-3126
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Wed, 16 Dec 1992 19:48:41 EST
Reply-To:     Andy Norton <76350.1604@COMPUSERVE.COM>
From:         Andy Norton <76350.1604@COMPUSERVE.COM>
Subject:      Re: PROC SORT NODUPLICATES is no good
Comments: To: SAS-L <SAS-L@AWIIMC12.IMC.UNIVIE.AC.AT>

----------------------------------------------------------------------
CONTENT:   Response
SUMMARY:   Phillip Tejera has not addressed the "adjacency" issue
REL/PLTF:  6.07.0304/CMS, 6.04/PC-DOS, beta 6.08/OS2
E-ADDR:    76350.1604@compuserve.com
NAME:      Andy Norton
ADDRESS:   Trilogy Consulting, 5228 Lovers Lane, Kalamazoo MI 49002 USA
PHONE:     (616) 344-2191
----------------------------------------------------------------------

Phillip Tejera says with regards to my NODUPLICATES posting

> The "key" here ( :-) ) is that Andy is using data where the key or
set of keys are NOT UNIQUE by design. That is, each observation does
not have a variable or combination of variables that are intended or
supposed to be different for every case.

No, this is not at all true.  I do have unique keys.  For the purposes
of this discussion, I have several (3 or more) observations for a
single key.  Rather than keeping only one observation per key, I want
to remove only exact duplicates for some hypothetical reason, perhaps
as Phillip says:
> As one is who would rather not casually discard data, I prefer
> NODUPLICATES, since I usually want to see items before they are
> discarded.

In my original posting, I included some test data:
> data TEST;
    input A B;
  cards;
  1 1
  1 2
  1 1
  run;

I think it would be useful to focus the discussion on this test data or
another proposed sample data set.

A is the key.  I have two extra records.  But I only want to delete
exact duplicates (otherwise I could just use NODUPKEY).  My problem is
that the two "1 1" records are not adjacent.  I sort by _ALL_ to make
them adjacent, not for any other reason.  Yes this is expensive, but I
need to make them adjacent in order to delete exact duplicates.

Note:  in real life I don't really ever do this.  I keep keys, and
remove duplicates on those keys.  But the discussion here concerns
NODUPLICATES which by definition has a different function than
NODUPKEY.  If you have 3 or more records for a given ID, and want to
delete only exact duplicates, NODUPLICATES needs those records to be
adjacent.  They won't necessarily be adjacent unless they are somehow
made to be adjacent.  One way to do this is to sort by _ALL_.
From: hilda@WILPAT.WILPATERSON.EDU (HILDA SPAGNA)
Newsgroups: bit.listserv.sas-l
Subject: PROBLEM SOLVED SAS TAPE READ SLOW
Date: 16 Dec 92 13:23:46 GMT
Reply-To: hilda@wilpat.wilpaterson.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Vms-To: SMTP%"@NJIN:SAS-L@OHSTVMA.BITNET"
X-Vms-Cc: HILDA
Comments: To: OHSTVMA.BITNET@pilot.njin.net


    This mail was not delivered, so I am sending it again:

                SOLUTION TO TAPE READ PROBLEM
    Regarding VAX SAS TAPE READ UNBELIEVABLY SLOW:
    In 5.18 a SAS program used "PUT" statements to create FIXED format records
    on DISK. Later, after user verified data, DCL copied disk to tape, a SAS
    step read the tape and printed it. THE RECFM WAS F.  NO problem.
    The problem arose when we went to SAS 6.07 and VAX 5.5-1.

    Now, the records are still created FIXED(as required by the state
    agency to which the tape is going) but I have changed the

    SAS INFILE statement to include RECFM=D in the SAS read and print program,

    as suggested by JOE at the University of Oregon.  Thanks, Joe.  It works
    in a flash! (the way it did before this problem)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-Path: <ecooch@sas.upenn.edu>
Posted-Date: Fri, 11 Dec 92 19:41:46 EST
X-Mailer: ELM [version 2.3 PL11-upenn1.8]
Newsgroups: bit.listserv.sas-l
Date:         Fri, 11 Dec 1992 19:41:46 EST
Reply-To:     Evan Cooch <ecooch@SAS.UPENN.EDU>
From:         Evan Cooch <ecooch@SAS.UPENN.EDU>
Subject:      benchmarks on SGI platforms...
Comments: To: sas-l%marist.bitnet@cunyvm.cuny.edu

Hi all...

For the past year or so, there has been a quick and dirty benchmark SAS
program run on a variety of platforms, with results generally posted to
the net (I contributed one for a NeXT computer several months ago).

  In 9 months I'll be working with an SGI 4D/380 (with 2 cpu's), and was
wondering if anyone out there has experience with  such a beast, has run
the benchmark, or has seen the results posted somewhere.  I'm doing most
of my work at present on RS\6000-350's, and 3090-type vector processed
mainframes running ESA. I'd like to know whether I'm sliding up or down
the performance pole.

Private responses, please.

If you have access to such a beast, and don't have the benchmark code, not
me and I'll send you a copy.




           _///_              +----------------------------+
           -. .-              |       Evan G. Cooch        |
           ( L )    \////     |   Department of Biology    |
         --(\=/)--  (   )     | University of Pennsylvania |
        /         \ /  /      | Philadelphia, Pennsylvania |
        I          V  /       |   Phone: (215) 898-7129    |
        I            /        |     FAX: (215) 898-8780    |
        I           /         | ECOOCH@MAIL.SAS.UPENN.EDU  |
                              +----------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Posted-Date:     16 Dec 92 14:15:57 EST
X-Pmrqc:  1
X-Mailer: Pegasus Mail v2.3 (R1).
Newsgroups: bit.listserv.sas-l
Date:         Wed, 16 Dec 1992 14:15:57 EST
Reply-To:     Ted Greenstein <TED@SERVER.SASW.NCSU.EDU>
From:         Ted Greenstein <TED@SERVER.SASW.NCSU.EDU>
Subject:      Re: merging 2 datasets together
Comments: To: SAS-L@VTVM2.CC.VT.EDU

There may well be a simpler way (and I'd like to hear if there is),
but this is a technique I often use.  Assume two datasets DATA1 and
DATA2 which contain some observations in common (case identifier is
ID).

PROC SORT DATA=DATA1; BY ID;
PROC SORT DATA=DATA2; BY ID;
DATA BOTH; MERGE DATA1 (IN=A) DATA2 (IN=B); BY ID;
IF A&B THEN OUTPUT;

The dataset BOTH will only contain observations that are in both
datasets, and I think that if there are common variable names, the
values from DATA1 will be retained.
Theodore N. Greenstein
307 1911 Building
Department of Sociology and Anthropology
North Carolina State University
Raleigh, NC 27695-8107

Voice: (919) 515-3114  FAX: (919) 515-2610
Email: ted_greenstein@ncsu.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Wed, 16 Dec 1992 15:16:31 EST
Reply-To:     Philip Tejera <TEJERA@BARUCH.BITNET>
From:         Philip Tejera <TEJERA@BARUCH.BITNET>
Subject:      Re: PROC SORT NODUPLICATES is no good
              14 Dec 1992 11:17:21 EST from <76350.1604@COMPUSERVE.COM>

On Mon, 14 Dec 1992 11:17:21 EST Andy Norton said:
>...
>SUMMARY:   Never use PROC SORT NODUPLICATES.
>           Use PROC SORT NODUPKEY instead.
>...
>So, NODUPLICATES only eliminates duplicates if they occur next to each
>other.  To get them next to each other, sort by all the variables.  But
>then you might as well use NODUPKEY right away:
>   proc sort data=TEST out=TEST2 nodupkey;
>     by _all_;
>...
>   1)  Is there any legitimate use of NODUPLICATES?
>       I suspect not.  My SAS 82 manual shows NODUPLICATES but not
>NODUPKEY.  My theory is that NODUPLICATES remains for compatibility,
>but NODUPKEY should always be used instead.

A major factor of Andy's suggestion is that "by _all_ ;" . Clearly, there
are big datasets with many variables and many observations where such a
sort would be prohibitively expensive, if not impossible.

The "key" here ( :-) ) is that Andy is using data where the key or set of
keys are NOT UNIQUE by design. That is, each observation does not have a
variable or combination of variables that are intended or supposed to be
different for every case. With this assumption, one no longer needs to
sort by all the variables, only by the identifying keys. Then NODUPLICATES
and NODUPKEY are usefully different in how they deal with the situations
when the keys are accidentally or erroneously duplicated.

As one is who would rather not casually discard data, I prefer NODUPLICATES,
since I usually want to see items before they are discarded.

I see there are more postings on this, but they have not really addressed
this issue. Perhaps there will be more later, but for those of us in
academia this is a very busy time of year. CAVEAT LECTOR !
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Sat, 19 Dec 1992 11:22:33 PST
Reply-To:     Melvin Klassen <KLASSEN@UVVM.BITNET>
Comments:     Warning -- original Sender: tag was NETNEWS@UVVM.UVIC.CA
From:         Melvin Klassen <KLASSEN@UVVM.BITNET>
Subject:      Re: Reading Variable Length Binary Files

S. David Riba <jadetech@ATTMAIL.COM> writes:
> I am trying to read a binary file into SAS.
> How do you read a variable length binary record when you do not have
> an end-of-record indicator, but can determine the record-length
> only while you are reading it?

DATA; INFILE BINARY LENGTH=LRECL;
     /* Read, and "hold" the record. */   INPUT @;
     /* Now read and "release" it.   */   INPUT RECORD $VARYING200. LRECL;
RUN;
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-VMS-To: IN%"sas-l@vtvm2.cc.vt.edu"
Newsgroups: bit.listserv.sas-l
Date:         Sat, 19 Dec 1992 22:57:00 EDT
Reply-To:     SHANK%UNCVX1.BITNET@VTVM2.CC.VT.EDU
From:         SHANK%UNCVX1.BITNET@VTVM2.CC.VT.EDU
Subject:      Book Ideas, this time with a signature
Comments: To: sas-l@VTVM2.CC.VT.EDU

The first message had everything but my name:

   Frank DiIorio

Once again: (919)942-2028
            102 Westbury Drive
            Chapel Hill, NC 27516-9154

Sorry. Didn't mean to be mysterious.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Fri, 11 Dec 1992 17:17:17 PST
Reply-To:     Melvin Klassen <KLASSEN@UVVM.BITNET>
Comments:     Warning -- original Sender: tag was NETNEWS@UVVM.UVIC.CA
From:         Melvin Klassen <KLASSEN@UVVM.BITNET>
Subject:      Re: Summary - CMS flat files from SAS

Paul Robertson <robertso@NPRDC.NAVY.MIL> writes:
> From the responses it was apparent that this problem is not uniformly noted
> across all CMS systems.
> ...
> WRT writing only RECFM=F files, I was told that SAS hardcodes a blocksize
> of 6400 for these files.
True & true.  You stated that you were running Version 5.18, and Version 6.
I'll bet that only Version 5.18 is guilty of writing one "short" record
into a 6400-byte-wide record, while this problem never occurs in Version 6.

Actually, it seems that Version 6 uses two approaches to sequential file-I/O:
 - if you use the FILENAME statement, and name a CMS disk-file, e.g.,
      FILENAME MYFILE 'FNAME FTYPE A' LRECL= 1234 RECFM=F;
   SAS will use the basic CMS file-I/O primitives to read/write the file,
 - if you use a FILEDEF statement, e.g.,
      CMS FILEDEF MYFILE DISK FNAME FTYPE A ( LRECL 1234 RECFM F;
   then SAS will rely on the "OS-simulation" code in CMS to read/write the
   file.  In this case, if you specify some LRECL value, and RECFM=F
   (or RECFM=FB), and you do **not** specify a BLOCK/BLKSIZE value,
   then SAS will set this value to:      FLOOR(1000/LRECL)*LRECL
   and will change your 'RECFM=F' specification to 'RECFM=FB'.
Either way, Version 6 will read/write your file.
(There are only a few pathological cases where the specific approach
for file-I/O will make any visible difference to your CMS file.
They're too esoteric to mention here!)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: The American University
Newsgroups: bit.listserv.sas-l
Date:         Fri, 18 Dec 1992 13:10:17 EST
Reply-To:     Julia Lane <JILANE@AMERICAN.EDU>
From:         Julia Lane <JILANE@AMERICAN.EDU>
Subject:      LIFEREG
Comments: To: sas-l@vtvm2.cc.vt.edu

I have been peering at the manuals all morning, and can not figure out whether
PROC LIFEREG  is fit to a hazard function or a survival function.  If it is the
 former, a positive coefficient means a firm (in my case) is more likely to die
; if the latter it means a firm is more likely to live!  Can anyone help?  I am
 the more worried since the coefficients on PROC LOGISITIC switched signs on me
 between versions 5 and 6, and the documentation is very confusing.  I am now u
sing 6.07.  TIA!
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Vms-To: SMTP%"@NJIN:SAS-L@OHSTVMA.BITNET"
X-Vms-Cc: HILDA
Newsgroups: bit.listserv.sas-l
Date:         Mon, 14 Dec 1992 11:15:24 -0500
Reply-To:     hilda@wilpat.wilpaterson.edu
From:         HILDA SPAGNA <hilda@WILPAT.WILPATERSON.EDU>
Subject:      ZCLEANUP
Comments: To: OHSTVMA.BITNET@pilot.njin.net

    SAS$WORKnnnnnnnn.DIR results in my home directory after using
    FSEDIT in SAS v607. I can delete it if I set default to it and then
    delete the contents, then the directory.  However, in training users,
    many of these are created, making the deletion a cumbersome process.

    The copyright 1986 SAS ZCLEANUP procedure runs but sends the message
    "no directories purged."  Purge to us (on VAX 5.5-1)means one remains.
    Each of these directories has a unique number, so none are purged.
    Help, anyone?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Wed, 16 Dec 1992 17:47:00 CST
Reply-To:     Sean Fahey <Y13SPF1@NIU.BITNET>
From:         Sean Fahey <Y13SPF1@NIU.BITNET>
Subject:      Rlink and "remote=async2"

I  have  recently reconfigured the interrupts for my serial ports and
can no  longer  use  "signon"  to  connect  via  com  2.   I'm  using
"remote=async2" to access com 2 which is now configured to use IRQ 5.
No  other  applications have any trouble using com 2 (Procom, Kermit,
etc..) which is connected to our mainframe via a Micom network.  When
I change the cables, set remote=async, and use com 1 everything works
fine.   This  may be because the IRQ and address setting for com1 are
the standard 3f8,4.  Since rlink always worked fine before,  is  this
problem  due  to the nonstandard IRQ 5 setting?  If so, are there any
fixes?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Wed, 16 Dec 1992 15:18:27 -0500
Reply-To:     jack.hamilton@AMAIL.AMDAHL.COM
From:         jack.hamilton@AMAIL.AMDAHL.COM
Subject:      re: merging two datasets together
Comments: To: apple!ohstvma.bitnet!sas-l@juts.ccc.amdahl.com

LISA KRIESE <ANSC413@ NLVM.BITNET> wrote:
>
>
> In SAS 5.18 I could write something like this :
>
>      data one; infile datain1;
>      input cow herd weight1;
>      proc sort; by cow;
>
>      data two; infile datain2;
>      input cow herd weight2;
>      proc sort; by cow;
>
>      data all; merge one(in=a) two(in=b); by cow; if a&b;
>
> and I would only keep cows that were present in both datasets.  When I
> try this in SAS 6.07 I get the message that reference to symbolic b is
> unresolved and I don't get the results I want.

A guess: SAS sees something of the form x&y and thinks "That's an imbedded
macro variable.  I'd better expand it."  When it tries  to do so, it can't
find a macro variable named 'b', so it gives an error message.

Why the difference between 5.18 and 6.06?  Your default system options for
macros have probably changed.  Run PROC OPTIONS and look at the values for
MACRO, MERROR, and the other macro options.  Also try running the program
with a space on each side of the ampersand.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer:     Pegasus Mail v2.3 (R3).
Newsgroups: bit.listserv.sas-l
Date:         Mon, 14 Dec 1992 10:17:44 EDT
Reply-To:     Ray Pass <PASSRAY@CPMAIL-NZ.CIS.COLUMBIA.EDU>
From:         Ray Pass <PASSRAY@CPMAIL-NZ.CIS.COLUMBIA.EDU>
Subject:      Which NY Airport for SUGI ?
Comments: To: SAS-L@uga.bitnet

A friend asked me which airport I would recommend using when coming to SUGI
18 in NY this spring.  My response?  Basically, they all stink.  Everytime I
land in NY I'm once again greeted by that something in the air, and on the
ground, that tells me I'm home.  Why is it that all other airports in the
civilized world are cleaner, friendlier, faster, easier to manage, etc, etc,
etc than any of the NY airports?  You may know my thoughts about the rotten
apple by now, but I think most people would agree with me about NY airports.

Anyway, back to the query.  I really think they're all about the same
convenience-wise.  I would make my choice based on other factors:  most
convenient flight times, preferred airline, non-stop flights, etc.  If they
were all the same, or it didn't matter, Newark is the easiest to deal with,
except it is the furthest away from the city.  Depending on when you land
however, that may not be a factor.  It could easily take longer to get in
from JFK or LGA if traffic is a bear.  I like LGA better than JFK, but that's
because I live much closer to it.  It is smaller and perhaps a little less
hustle-bustle, but not much.  Ground transportation rates are as follows,
according to the SUGI registration packet (all approx):

    TAXI - LGA $20-$25   JFK $35-$40   EWR $40
    BUS  - LGA $12       JFK $15       EWR $17

The packet mentions a share-the-ride taxi program at LGA, but I imagine its
available at the others also.  Rental car rates are all comparable I'm sure,
but then you've got to deal with a car in Manhattan!  Why do that ?  My
recommendation?  Stay home.  Seriously, I would choose the airport based on
other factors.  See youse guys in da spring.

Ray



 *--------------------------------------------------------------------------*
 | Ray Pass, Ph.D.                                    Voice: (212) 305-7748 |
 | Columbia-Presbyterian Medical Center                 Fax: (212) 305-3302 |
 | 161 Ft. Washington Ave.       AP1310                                     |
 | New York, NY 10032-3784               passray@cpmail-nz.cis.columbia.edu |
 *--------------------------------------------------------------------------*
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.sas-l
Date:         Fri, 11 Dec 1992 15:44:34 EST
Reply-To:     Michael Davis <75046.1627@COMPUSERVE.COM>
From:         Michael Davis <75046.1627@COMPUSERVE.COM>
Subject: Re: STACKER
Comments: To: sas-l@uga.cc.uga.edu

-----------------------------------------------------------------------
CONTENT:    Response Re:  Experience with Stacker Disk Compression
SUMMARY:    Stacker, SuperStor work with SAS
REL/PLTF:   All Releases/MS-DOS, Windows
E-ADDR:     0002395748@mcimail.com
P-ADDR:     BC&BS OF Conn., 370 Bassett Road, North Haven, CT 06473
PHONE:      (203)-985-7187
FAX:        (203)-985-7030
-----------------------------------------------------------------------

Jay J. Wind <JWJ%NCCIBM1.BITNET> asks if anyone has experience using
SAS from a STACKER drive?  While I have no direct experience with
STACKER, I have chatted with SI Tech Support about it and they tell
me that SAS works fine with STACKER.

I use SuperStor on my home computer and SAS runs fine with it, with
about a 5-10 percent reduction in performance.  However anyone considering
using STACKER or SuperStor should consider the following:

1.  Back-up fully before installing.
2.  Reserve an uncompressed portion of the disk for programs which
    need it, such as the swap file for Windows.
3.  Disk compression software is often uncompatible with programs
    that bypass BIOS routines such as disk utilities.
4.  Talk to your network folks before installing on a LAN client.

SuperStor (and probably STACKER) cannot be used on a Novell Netware file
server nor with OS/2.  Folks running under Windows are good candidates
for disk compression since they do not have to worry about the 640K
conventional memory limit.

Use of disk compression software represents a trade-off between saving
money but spending more time setting up and maintaining your computer
system.  If I had the problems JWJ mentioned, I'd flush the software and
buy a bigger hard drive.


Distribution:
  >internet: sas-l@uga.cc.uga.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU