Date: Wed, 21 Mar 2001 21:42:23 -0500
Reply-To: don.henderson@US.PWCGLOBAL.COM
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: don.henderson@US.PWCGLOBAL.COM
Subject: Re: SAS/Intrnet
Content-type: text/plain; charset=us-ascii
I pretty much agree with Mike's comments on AppDev Studio. But one thing
you should be clear about is what AppDev Studio is. It is a developers
bundle for you to build web based apps, whether you are using webAF/webEIS
or just the CGI tools. You still have to separately license IntrNet on a
server somewhere. At least this was the case the end of last year. It might
have changed, and so Mike's suggestion to check with your Account Rep is a
good one. That also explains why you can redistribute your Java apps you
build with webAF/webEIS. They still need to talk back to SAS on a properly
licensed server.
I will caution you however, that if you want to build anything beyond the
basics and you want to use webAF or webEIS you will have to have folks who
know Java - and know it pretty well.
If you have folks who know SAS and SCL, using the cgi-based MDDB Report
Viewer might be the place to start. You can then move to webAF/webEIS if
you need to. Both will require IntrNet on a server somewhere.
Next, to the issue of where to host your SAS server (whether is it the
server that webAF/webEIS talks to, or the Application Server), I have to
disagree with Sig's comments earlier in this thread. He was correct that
the architecture of IntrNet is such that you can distributed the pieces
(e.g., the web server on one box, and the SAS server on another). However,
you do want to put you SAS server close to your data. And I think your AF
app that you say has given you problems is probably evidence of that. The
problem you LIKELY (in caps, because I am not sure if this issue has been
addressed yet by our friends at SAS) due to the fact that when you access
an MDDB remotely from a SAS client, it has to move lots of data across the
wire before it can decide what to do (and this problem is exacerbated if
you don't have all the appropriate crossing stored in your MDDB). So, if
you put your SAS Server on a different box than where the MDDB is, you will
have repeated the same problem, but made it worse, because now once the SAS
server is done, instead of just diplaying it on the screen, it now has to
stream back, via the web server, the HTML for display in your browser.
HTH,
-don
Michael Davis <sas-l@BASSETTCONSULTING.COM>@LISTSERV.UGA.EDU> on 03/21/2001
08:06:09 PM
Please respond to Michael Davis <sas-l@BASSETTCONSULTING.COM>
Sent by: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
To: SAS-L@LISTSERV.UGA.EDU
cc:
Subject: Re: SAS/Intrnet
Hello Jit,
You asked whether your organization needed AppDev Studio. For what it is
worth, here is my recommendation given what you've related:
You can view MDDBs with just SAS/IntrNet alone via the MDDB Report
Viewer. The viewer gives very good performance when bandwidth to the
application server is an issue (e.g., dial-up connection).
If you want SAS/EIS functionality in a thin-client flavor, you should
investigate webEIS, which is part of AppDev Studio. Keep in mind that
while some might find the per-seat cost of the AppDev Studio development
environment pricey, the Java applets created via AppDev Studio can be
distributed royalty free. So your "per seat" costs are only those for
running SAS on the server. The more concurrent users you have, the bigger
the server you'll need.
One big problem with webEIS that is going away is the size of the JAR
files, which contain the compiled classes. Even on a good LAN, downloading
the JAR file to your browser each time you need to run something is not
attractive. In a dial-up situation, it becomes downright ugly. And I
haven't even covered the problem of differing plug-ins and Java support on
various browsers.
Fortunately, AppDev Studio 2.0 fully supports Java Server Pages (JSP),
which causes the generated Java code to run on the server. You'll need a
Java application server, such as JRun. I'm also pretty sure that you'll
want to license SAS/SHARE (or perhaps SPDS) to access SAS libraries via
TCP.
For what it is worth, I think that your SAS Account Representative will
give you a pretty honest and accurate recommendation with respect to the
SAS products you ought to license. The sizing of the server is up to your
organization to figure out. If you go with a multiple processor NT
machine, make sure that the vendor supplies load-balancing software because
V8 SAS and NT will not use the additional processor without some external
"coaxing".
- Michael "Mad Doggy" Davis
At 09:21 AM 3/21/01 -0500, Jit Bhattacharya
<jit.bhattacharya@PRUDENTIAL.COM> wrote:
>Mike Davis and Ming gave me some tips on SAS/Intrnet - but I guess I need
>to go
>into some details - problem is, I do not know them all, but I will try.
>
>Our company has a Unix server with 4 processers and about 100 GB of space
- we
>have very large datasets. we are also thinking about allocating an NT
>machine to
>act as a web server. Our intent is to explore possibilities to use
>SAS/Intrnet.
>Currently we have a SAS/AF application that is used by 100 users to access
the
>Unix datasets. Our experience with this 'fat client' has not been all
>positive,
>so we are thinking of switching to SAS/Intrnet, if feasible. Our datasets
>have ,
>on average, 4 million obs, with some with as many as 50 million obs. Our
>current
>application enables drilldown on MDDBs that are viewed with an EIS object.
We
>would like to have this capability with Intrnet. other than this, our
>basic need
>is for users to choose certain parameters, and start SCL/SAS code to show
a
>report. We wanted to know what are the implications of moving to Intrnet.
I
>would say, at any given time, not more than 7-8 users would run reports.
>Should
>we be getting Appdev Studio? or can we do without it?
>
>Jit
Michael L. Davis
Vice President
Bassett Consulting Services, Inc.
10 Pleasant Drive
North Haven CT 06473-3712
E-Mail: michael@bassettconsulting.com
Web: http://www.bassettconsulting.com
Telephone: 203-562-0640
Facsimile: 203-498-1414
Messages: 888-477-1412
----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
