Date:         Thu, 8 Nov 2001 11:59:16 -0500
Reply-To:     Jim Agnew <agnew@HSC.VCU.EDU>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Jim Agnew <agnew@HSC.VCU.EDU>
Organization: Virginia Commonwealth University
Subject:      Re: debate on SAS vs other languages
Content-Type: text/plain; charset=us-ascii

I'm in the same boat here...  I've tried to email SAS about these
dratted odbc drivers, and my option now is to backtrack to SAS 6 from
SAS 8, and keep 2 computers via a kvm switch on my desk, one for sas 8
which i have to have for one reason, and sas 6 for this...

VMS never did that to us w/o warning.. and that was only from v4 to
v5..  sigh..

i expect something like this from Microsoft, but NOT SAS...

Jim

Charles Patridge wrote:
>
> Hi Sterling,
>
> Until recently, I would have voted very much in favor of having SAS as a
> tool set given its completeness and reliability to work well with its own
> products as opposed to building one's own set of tools to do the same thing
> as SAS.
>
> However, over the past several years, I have seen SAS moving towards
> splitting up some products into new modules, hence have to license more
> products and paying more to do the same thing as before.
>
> Also, it seems to acquire some new features of SAS, you have to buy more
> products than you first might expect which is an ongoing "JOKE" at THE
> HARTFORD.  That is, so how much does this product cost???  Oh.  Oh, by the
> way, WHAT ELSE DO WE NEED TO LICENSE TO GET THIS TO WORK IN OUR
> ENVIRONMENT???  Typical answer is another $40K to make it ALL WORK.
>
> Finally, our most recent experience is with our current application where we
> use MS Excel as a FRONTEND to capture input data from our internal
> customers, and then launch as SAS job on our NT server which in turn
> launches as SAS Connect job to our Alpha to perform our various SAS models
> to generate output back to our Excel Frontend.
>
> Under V6.12 everything works just fine.  Now in Version 8.2, we are finding
> that we need to re-do our VBA code to launch SAS via IOM to our NT server
> and we are still waiting to find out if we need to license IOM for our Alpha
> as well in order to get everything to work as before.
>
> It is quite upsetting to see a well running and behaved application as ours
> to be turned upside down with a new release of SAS and NOT function ANYMORE
> because we have to license more products.
>
> It would be one thing is the cost was minimal, say $under 5K, but we are
> talking in the area of $40K.  And we are not talking about adding any more
> new features or functionality to our current application other than to make
> it work as before.
>
> In addition, it appears to make this work under IOM requires some expertise
> in VBA that most of us are not skilled at.
>
> I know you provided me with some examples of your solution but it will not
> work in our environment (SAS V8.2 on an NT server).  My LAN administrator
> believes you may be operating with a different release of SAS or your
> environment it slightly different than ours.
>
> In any case, the question of looking at other tools besides SAS may very
> well be in our future strategy.
>
> There comes a time when software vendors need to increase functionality
> without the need to require more products to maintain current needs.
>
> Now, it may seem that I am blowing off some steam because of our V8.2
> situation but I am trying to look back over the past 20 plus years I have
> been using SAS software, and I agree the software has gotten better, but
> also more expensive, products being split into new products, and the need to
> buy more products to get things to work.
>
> Will we re-write our SAS code??? At this time, probably not.  But it is a
> question we are more serious than ever thinking about.  More importantly, it
> is the feeling that as customers, we are starting to feel our hides are
> being stretched over a barrel for a good tanning.  And our management does
> not take kindly to this situation.
>
> This is my 2 cents, and please remember, I do love SAS's capabilities and
> tool sets.  But, how much am I willing to spend, and for how long, is
> another story.
>
> Best Regards,
> Charles Patridge
> The Hartford
> Corporate Actuarial
> Email: Charles.Patridge@thehartford.com