Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!NUHUB.ACS.NORTHEASTERN.EDU!JOHNSON
From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP
Newsgroups: mod.computers.vax
Subject: SAS & SPSSX
Message-ID: <8702200347.AA06010@ucbvax.Berkeley.EDU>
Date: Thu, 19-Feb-87 08:54:00 EST
Article-I.D.: ucbvax.8702200347.AA06010
Posted: Thu Feb 19 08:54:00 1987
Date-Received: Sat, 21-Feb-87 01:33:11 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 49
Approved: info-vax@sri-kl.arpa


     >I will be acquiring SAS or SPSS for a VAX/VMS
     >system and would like to hear about any comments
     >people have on running SAS or SPSS.  How big are
     >these packages, are they well structured for VMS,
     >etc.  Please reply directly to me and I will
     >summarize if people want. 
     >
     >Robert McQueen
     >Stevens Institute of Technology
     >BITNET: RMCQUEEN@SITVXA
     >-------

     At Northeastern University we have both.  SPSSX takes up 
10490/10592 blocks.  SAS takes up 80356/81144 blocks.  This is full 
blown on both.  There are probably parts you can do without if you need 
the space.  They both run on VMS.  They both like to open lots of work 
files, sometime not where you expect them to be open.  They also both
love LOTS of virtual memory and working sets of 1000 to 1800 plus pages
in order to work well. 

     SAS has bugs and there are things that will run on IBM SAS that 
will NOT work on VMS SAS.

     SPSSX's installation procedure has bugs/bad features and is
generally hell to run.  SPSSX has bug too.  Also, the installation 
procedure understand about VAXclusters and will define some
logicals that won't work right on a cluster with out some fiddling. 
Further, if you have Datatrieve and link SPSSX with it, when Datatrieve
changes SPSSX breaks.  You need to relink SPSSX which means running that
horrible installation procedure again. 

     SPSSX Inc. is generally bad to deal with when there is a bug.  It's 
hard to find someone to talk to who knows something.  They often don't 
call back and need to be nagged at to get a response.

     SAS is better to deal with.  They call back.  The answer might be 
"Oh, that's a bug." but at least you get an answer and an 
acknowledgement of the problem.

     The above opinions as to software support are the result of having 
to deal with both companies.

Chris Johnson
Northeastern University

csnet:      johnson@nuhub.acs.northeastern.edu
arpa:       johnson%nuhub.acs.northeastern.edu@relay.cs.net
at&t:       (617) 437-2335