f



License question SAS/SHARE and SAS/ACCESS vs. SAS/IntrNet

Hello,

I was wondering if any of you experienced SAS users could help.  My
small clin. software company is in the process of reviewing their SAS
license, i.e. finding a cheaper solution than the constellation we are
currently using:

SAS / ACCESS + SAS / Share + SAS / Connect + SAS / IntrNet

Our SAS server is currently handling some (not all) reporting duties
for the main J2EE-type application that has a back-end DB2 database. 
We are using SAS/ACCESS to copy our db2 tables and then performing
roll-ups / summaries and proc means in batch at night.  SAS then
delivers tabulated reports and graphics in real-time using SAS/IntrNet
/ Integrated Object Module.  We don't really want to throw out our SAS
libraries and code (it after consists of over 5 man-years of labor!) 
so we are considering what different options we have:

- use a SAS/SHARE driver for JDBC (see information below)?  in this
scenario we access our SAS server (read-only) from a connected
application server and run queries against the SAS tables.  We still
would require the SAS/ACCESS to copy db2 and then perform the nightly
batch in SAS.  Would we save $$$ over our current configuration, in
your opinion?

- use SAS/SHARE driver for ODBC?
- other solution?

p.s. in case you were wondering, yes this situation is a result of
budget constraints!  And yes it looks like I will not be here too much
longer :-)

Appreciate your help-

Kent Lewandowski

--------
Requirements for the SAS/SHARE� Driver for JDBC
The SAS/SHARE driver for JDBC is fully compliant with the JDBC 2.0
API. It implements the basic 2.0 Core functionality but does not
implement the advanced 2.0 Core features of scrollability, batch
update, and programmatic update. Before you can write and deploy
programs using the classes that are provided with the SAS/SHARE driver
for JDBC, your intranet must meet the following requirements:
Your Java environment supports JDK 1.4.1. Note: An earlier version of
the JDK might work but is not supported by SAS.
Your SAS server is running SAS, Version 6 or later. SAS/SHARE software
is installed as part of your SAS server.
Your Web server runs on the same machine as your SAS server or has
network access to the machine running your SAS server.
0
kentlewan (13)
7/7/2004 10:19:36 AM
comp.soft-sys.sas 142827 articles. 3 followers. Post Follow

6 Replies
1048 Views

Similar Articles

[PageSpeed] 22

Kent Lewandowski wrote:
> Hello,
>
> I was wondering if any of you experienced SAS users could help.  My
> small clin. software company is in the process of reviewing their SAS
> license, i.e. finding a cheaper solution than the constellation we are
> currently using:
>
> SAS / ACCESS + SAS / Share + SAS / Connect + SAS / IntrNet
>
> Our SAS server is currently handling some (not all) reporting duties
> for the main J2EE-type application that has a back-end DB2 database.
> We are using SAS/ACCESS to copy our db2 tables and then performing
> roll-ups / summaries and proc means in batch at night.  SAS then
> delivers tabulated reports and graphics in real-time using SAS/IntrNet
> / Integrated Object Module.  We don't really want to throw out our SAS
> libraries and code (it after consists of over 5 man-years of labor!)
> so we are considering what different options we have:
>
> - use a SAS/SHARE driver for JDBC (see information below)?  in this
> scenario we access our SAS server (read-only) from a connected
> application server and run queries against the SAS tables.  We still
> would require the SAS/ACCESS to copy db2 and then perform the nightly
> batch in SAS.  Would we save $$$ over our current configuration, in
> your opinion?
>
> - use SAS/SHARE driver for ODBC?
> - other solution?
>
> p.s. in case you were wondering, yes this situation is a result of
> budget constraints!  And yes it looks like I will not be here too much
> longer :-)
>
> Appreciate your help-
>
> Kent Lewandowski
>
> --------
> Requirements for the SAS/SHARE� Driver for JDBC
> The SAS/SHARE driver for JDBC is fully compliant with the JDBC 2.0
> API. It implements the basic 2.0 Core functionality but does not
> implement the advanced 2.0 Core features of scrollability, batch
> update, and programmatic update. Before you can write and deploy
> programs using the classes that are provided with the SAS/SHARE driver
> for JDBC, your intranet must meet the following requirements:
> Your Java environment supports JDK 1.4.1. Note: An earlier version of
> the JDK might work but is not supported by SAS.
> Your SAS server is running SAS, Version 6 or later. SAS/SHARE software
> is installed as part of your SAS server.
> Your Web server runs on the same machine as your SAS server or has
> network access to the machine running your SAS server.

If you have a DB2 programmer *and* DB2 has the ability to utilize JDBC, then
you could have a DB2 process *push* the data into SAS tables (via JDBC and
SAS/Share) instead of pulling the data from DB2 via SAS/ACCESS, thus being
able to drop SAS/ACCESS from your package.

(According to the principle of conservation of annoyances, the savings in
dollars will be lost in the losing of time :)  It might take alot longer to
push into SAS than to pull from DB2.  You will have to do some benchmarking
to determine if push is viable and time appropriate.

-- 
Richard A. DeVenezia
http://www.devenezia.com/downloads/sas/macros


0
radevenz (1543)
7/7/2004 1:31:17 PM
Hi Richard,

Thanks for the tip.  I agree with your "principle of conservation of
annoyances".  The savings from dropping SAS /ACCESS would not be very
good.

What I am more interested in, is how much do you think we would save
by dropping SAS/IntrNet?

Don't get me wrong- I like SAS 8.2 - but I'm only asking cause we need
to make some budget decisions.  Having our SAS rep. come down here and
get in negotiations before we know what options are available is not
going to help us either.

Kent


"Richard A. DeVenezia" <radevenz@ix.netcom.com> wrote in message news:<2l2c8kF7k5csU1@uni-berlin.de>...
> Kent Lewandowski wrote:
> > Hello,
> >
> > I was wondering if any of you experienced SAS users could help.  My
> > small clin. software company is in the process of reviewing their SAS
> > license, i.e. finding a cheaper solution than the constellation we are
> > currently using:
> >
> > SAS / ACCESS + SAS / Share + SAS / Connect + SAS / IntrNet
> >
> > Our SAS server is currently handling some (not all) reporting duties
> > for the main J2EE-type application that has a back-end DB2 database.
> > We are using SAS/ACCESS to copy our db2 tables and then performing
> > roll-ups / summaries and proc means in batch at night.  SAS then
> > delivers tabulated reports and graphics in real-time using SAS/IntrNet
> > / Integrated Object Module.  We don't really want to throw out our SAS
> > libraries and code (it after consists of over 5 man-years of labor!)
> > so we are considering what different options we have:
> >
> > - use a SAS/SHARE driver for JDBC (see information below)?  in this
> > scenario we access our SAS server (read-only) from a connected
> > application server and run queries against the SAS tables.  We still
> > would require the SAS/ACCESS to copy db2 and then perform the nightly
> > batch in SAS.  Would we save $$$ over our current configuration, in
> > your opinion?
> >
> > - use SAS/SHARE driver for ODBC?
> > - other solution?
> >
> > p.s. in case you were wondering, yes this situation is a result of
> > budget constraints!  And yes it looks like I will not be here too much
> > longer :-)
> >
> > Appreciate your help-
> >
> > Kent Lewandowski
> >
> > --------
> > Requirements for the SAS/SHARE� Driver for JDBC
> > The SAS/SHARE driver for JDBC is fully compliant with the JDBC 2.0
> > API. It implements the basic 2.0 Core functionality but does not
> > implement the advanced 2.0 Core features of scrollability, batch
> > update, and programmatic update. Before you can write and deploy
> > programs using the classes that are provided with the SAS/SHARE driver
> > for JDBC, your intranet must meet the following requirements:
> > Your Java environment supports JDK 1.4.1. Note: An earlier version of
> > the JDK might work but is not supported by SAS.
> > Your SAS server is running SAS, Version 6 or later. SAS/SHARE software
> > is installed as part of your SAS server.
> > Your Web server runs on the same machine as your SAS server or has
> > network access to the machine running your SAS server.
> 
> If you have a DB2 programmer *and* DB2 has the ability to utilize JDBC, then
> you could have a DB2 process *push* the data into SAS tables (via JDBC and
> SAS/Share) instead of pulling the data from DB2 via SAS/ACCESS, thus being
> able to drop SAS/ACCESS from your package.
> 
> (According to the principle of conservation of annoyances, the savings in
> dollars will be lost in the losing of time :)  It might take alot longer to
> push into SAS than to pull from DB2.  You will have to do some benchmarking
> to determine if push is viable and time appropriate.
0
kentlewan (13)
7/8/2004 10:36:32 AM
Kent Lewandowski wrote:
> Hi Richard,
>
> Thanks for the tip.  I agree with your "principle of conservation of
> annoyances".  The savings from dropping SAS /ACCESS would not be very
> good.
>
> What I am more interested in, is how much do you think we would save
> by dropping SAS/IntrNet?

I don't know.  It's more a question of
- per Base licensing what modalities of SAS output delivery or SAS
processing accesses via web services are legal.
    - search the archives for prior threads.
- For modalities not legal without SAS/Intrnet, are there alternative
technologies to accomplish same or near-same
    - what is the cost of the work around ?
    - at one point in the past there was something called Onyx (David Ward),
but I think that has gone poof.

If you can identify what parts of your processes or planned processes will
or might use which components of SAS/Intrnet, then you can get a much better
idea of how critical it is to have (or not)

> Don't get me wrong- I like SAS 8.2 - but I'm only asking cause we need
> to make some budget decisions.  Having our SAS rep. come down here and
> get in negotiations before we know what options are available is not
> going to help us either.

Granted a rep might not be uber-diligent in helping find a way to not use a
SAS product, but they certainly should be able to discuss the benefits at
length.

-- 
Richard A. DeVenezia


0
radevenz (1543)
7/8/2004 4:23:36 PM
Kent Lewandowski wrote:

> What I am more interested in, is how much do you think we would save
> by dropping SAS/IntrNet?

Quick retraction after a little searching. Onyx did not go poof, it became
Axom.
http://www.axomsoftware.com/

From documentation at
http://www.axomsoftware.com/axom.htm
"Axom provides similar technology to the following SAS products:
SAS/Intrnet, WebAF, Enterprise Integration Technologies, and SAS/Connect,
but at a significantly reduced cost."

I have never used Axom, nor am I connected to it in any way.
-- 
Richard A. DeVenezia


0
radevenz (1543)
7/8/2004 4:34:40 PM
Nice to know that Onyx did not go away. They probably had to rename it due
to the fact that there is/was another product (a CRM product) call Onyx that
likely had the name locked up first.

One note about evaluating other products that "provide functionality to
SAS/IntrNet" is to make sure that using them is within the terms of your
license agreement with SAS. Part of the price of SAS/IntrNet is the fact
that it includes a license to allow your "employee" to access and run SAS
program via a browser. If your SAS license is such that you have a fixed
number of users, and if by deploying over the web, you will exceed that
number (total users, not concurrent ones), then you (in order to stay
"legal") will have to pay SAS to allow that. And the price for that,
combined with the price for the other products, may be more than the license
fee for IntrNet.

HTH,
don henderson

----- Original Message -----
From: "Richard A. DeVenezia" <radevenz@IX.NETCOM.COM>
Newsgroups: bit.listserv.sas-l
To: <SAS-L@LISTSERV.UGA.EDU>
Sent: Thursday, July 08, 2004 12:34 PM
Subject: Re: License question SAS/SHARE and SAS/ACCESS vs. SAS/IntrNet


> Kent Lewandowski wrote:
>
> > What I am more interested in, is how much do you think we would save
> > by dropping SAS/IntrNet?
>
> Quick retraction after a little searching. Onyx did not go poof, it became
> Axom.
> http://www.axomsoftware.com/
>
> From documentation at
> http://www.axomsoftware.com/axom.htm
> "Axom provides similar technology to the following SAS products:
> SAS/Intrnet, WebAF, Enterprise Integration Technologies, and SAS/Connect,
> but at a significantly reduced cost."
>
> I have never used Axom, nor am I connected to it in any way.
> --
> Richard A. DeVenezia
>
0
7/8/2004 5:09:52 PM
Thanks, guys, I am going to contact AXOM.

Kent
0
kentlewan (13)
7/12/2004 11:35:58 AM
Reply: