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 (December 1999, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Wed, 15 Dec 1999 12:02:57 +1100
Reply-To:     Tim CHURCHES <TCHUR@DOH.HEALTH.NSW.GOV.AU>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Tim CHURCHES <TCHUR@DOH.HEALTH.NSW.GOV.AU>
Subject:      Re: SAS/IntrNet licensing (was Re: Perl)
Comments: To: dward@sashelp.com
Content-Type: text/plain; charset=US-ASCII

David,

It sounds like we, and anyone else working on similar projects, ought to collaborate. One of our requirements which SAS/IntrNet has failed to address is the need to have one SAS server session per user (so the user's job always starts running immediately instead of being queued up for an unknown length of time) with that user-specific SAS server session running in that particular user's security context. SAS/Connect works like this, and it is possible to build AppDev Studio/webAF applications which also work like this (since it uses the SAS/Connect infrastructure for client Java app to SAS server communications), but SAS/IntrNet does not support it. What SAS/IntrNet provides is a pool of SAS server processes which is OK for servicing anonymous Internet users, but not ideal for servicing know and authenticated intranet users.

It is definitely worth looking into the legalities of the licensing issues - my reading is that any Web-based interactive application which uses SAS and which is accessible by anyone from the Internet is probably in violation of your SAS license unless you also license SAS/IntrNet, but that there are no licensing problems with deploying Web-based applications on an internal intranet (or even an extranet which is accessible to employees only) even in the absence of a SAS/IntrNet license.

All these licensing issues (not to mention the concommitant fees) only make us even more keen on Conceptual Software's forthcoming DBMS/Web product, which is DBMS/Analyst (which itself is a Base SAS work-alike) optimised for Web applications. It can both read and write SAS datasets (and just about everything else) in place, no need to convert or migrate your data, so it would fit in nicely with existing SAS installations. I don't know what the cost or licensing arrangements for DBMS/Web will be, but judging by the cost and the (perpetual, not annual) licensing arrangements for DBMS/Copy and DBMS/Analyst, it is likely to be highly affordable and have a very flexible license, including perpetual unlimited server site licenses for just a few thousand dollars. And it will be available for Linux, so you could set up a farm of Linux-based DBMS/Web servers for a fraction of the cost of the SAS equivalents - very scalable at low marginal cost. Certainly of interest to those of us for whom the price does matter!

Tim Churches

>>> dward <dward@SASHELP.COM> 12/15/99 09:46am >>> My job for the second half of this year has involved exactly what Tim is discussing. I've come up with a replacement for SAS/Intrnet using Base SAS/SCL, and Perl. The legal implications are a little frightening though... My company hasn't investigated what this will mean to our clients who will be purchasing the software.

The code is simple enough, as Tim mentioned. I'll probably post as much of it as I can (I'll need to see what is proprietary) soon to SASHelp.com and let you know when it is available.

Our Internet product combines persistent sessions with session management, none of which SAS/Intrnet does. These were features that were vital to the success of our current product.

One huge problem with custom CGI interfaces to SAS is that, to my knowledge, SAS can't truly act as a server by supporting simultaneous multiple TCP/IP connections. I'm stuck with one at a time until I can kick off a separate session that is dedicated to only one user.

David Ward SASHelp.com

> In our case, cost constraints and the fact that we only deploy > SAS/IntrNet on our intranet has caused us to drop > our SAS/IntrNet license - we will be replacing it over the next 6 > months with a mix of in-house SCL and Perl code > as the glue between Web forms and SAS as the back end. I'll be happy > to share these developments on SAS-L > as the code matures (and as time permits). > > Tim Churches > Sydney, Australia

-- ---------------------------------------- David L. Ward, Senior Software Developer DZS Software Solutions, Inc. Bound Brook, NJ SAS Related: dward@sashelp.com Work Related: dward@dzs.com ---------------------------------------- --


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